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LDOS: Utilities, Trainers & Systems Programming On The Old ZX-81/TS1000 p.11-f 


There are probably three reasons for doing systems emulation/simulation and 
utilities on the ZX-81/TS1000 home computer equipped with the LDOS disk system, 
The most practical reason is to solve a problem that you as user may have encount- 
ered in using the computer for a serious purpose, personal or commercial, The few 
remaining commercial uses of the ZX-81/TS1000 are in industry and home use in whic 
the computer controls the workings oi a machine or monitors an alarm system, etc,anc 
secondarily, when the system serves to develop programs for use in either a et 
ZX-81/TS1000 board used as a controller as just mentioned (or a short ZX-ROM peb) or 
another Z-80 controller board, Since m/c means crashes and crashes mean reload- 
ing the program in the computer, the disk drive system offers the next significan 
way of speeding up méc development on e - eyon e production Oo 1 
Soitware assemblers, disassemblers and debuggers written for the computer years ag 
Tape is so tedious on the ZX-81/TS1000 that this reloading usually causes most m/c 
amateurs to give up on m/c learning after about the fourth reload of the software 
from tape, Unfortunately, the other important factor in m/c development, the use 
of assemblers and debuggers, is hard to integrate with the LDOS Syston which came 
Tater, so that the gap may need to be filled by utilities custom written for the 
ZX-81/ TS1000 LDOS system, It is this systems programming that-this chapter aids. 

Let us follow a typical session of-a m/o subroutine developer, —First-an-assez- 
bler is loaded in from disk, the instructions for saving it to disk and getting it 
Started having been followed from experiments at a previous session in adapting th: 
software for the LDOS system, (See our chapter 3 for concrete examples), The prog- 
ram ig.te be .done with th assembler, in Z-80 assembly language, with the addition o: 
a short routine at its beginning that the developer adds to all programs being tes: 
ed this way, It will call^ a subroutine above RAMTOP to save the whole block of 
ZX-81/TS1000 RAM in which the assembly language code is, to disk, Then the m/c 
routine being developed is run. It causes the computer to crash, meaning the key- 
board locks up and will not respond to any commands. The computer power is unplug- 
ged, the software reloaded, and a m/c routine above RAMTOP (another one) called to 


"Eget the source code just completed off disk into RAM so that it can be examined to 


see where the error may be that caused the probiem. Over and ovér this cycle of 
test, crash and reload occurs, this little utility saving the developer from typin: 
or writing down the source code by hand before each new test that may cause the 
computer to lock-up (at which point RAM is no longer accessible and the program car 
at that point never be retreived, On. the ZX-81/TS1000, as with nearly all other 
types of computer when they crash), This section of the book will offer some hints 
on writing such utilites to fill in the c between sofware based on cassette and 
its use wi the lsk-equippe - ° ittle utility or two can hely 
Other uses of utilities for making database and wordprocessing routines work bette: 
are a simpler way of illustrating how utilites work into the LDOS system and in th 
such applications are easier to understand and can be written in BASIC, extensive 
coverage of them is supplied here, In short they offer a taking off point for the 
programmer who would redo those types of routines in m/c or as a part of a more 
technically involved utility using BASIC with n/ c subroutine, LDOS-ROM calls. 

Ihe second use of utilities in the ZX- and indeed even more, 
the sort of systems routines that utilities are built on, is in the fantasy world c 
trying to do things on your ZX-81/TS1000 that would normally be considered too com- 
plicated for such a small and limited computer, ...You know-what-I- mean, Friday;--——- 
holiday weekend, rainy, dreary day or snowstorm, it is predicted to last for the 
whole holiday and you get out your ZX-81/TS1000 and say,"Maybe I should just try 
that little routine that I saw running on a VAX, that neat command system, screen 
display, etc, just a few hours?", and three days later after innumerable hours of 
time quickly passed in the diversion of this computer programming hobby, you emerge 
with the beginnings of a very fancy simulation of some ancy System, a new apprecia 
tion of the basics of computer software design and your imagination and ambition 
recharged for another week of more serious human activity. Why do people write 
such programs? Perhaps you may want a ''toyt*wersion of. a System they have used at 
Work or in school, or always wanted to use, but never had enough VAX access time, 
or the expensive software it needed to ran on.an IBM home computer cost too much. 
Well, perhaps an unimplemented idea is to a software enthusiast like an unclimbed 


mountain is to a mountaineer. Why do they climb them? Because bhey are there, 
However, the end result is peter ay very, very educational, so that such a program- 


mine project begun as a whim, end5 up as a trainer with definite educational use, 
and it is education that is He tnra Major USS Of the rips Monts Seer 


Experimenting With Disk Systems, Alternative Command Sets, Etc, pell-1 

The Sinclair ZX-8l/Timex TS1000 was and is primarily an experimenter's comput- 
er, It is good for the learnerof programming or simple computer literacy in school | 
or past school age. Fortunately the experimentaion with I/O using the ZX-81/ 
TS1000 is not limited to cassette saves and loads and a little printer experiment- | 
ing. Now, with the LDOS disk interface, all the ramifications of floppy disk use | 
including the nuts and bolts of software and disk operating system program struct- | 
ure can be explored by the ZX-81/TS1000 owner with:a technical bent, Don't bother! 
reading this chapter further if you are not curious about how disk systems work by | 
the nuts and bolts deep insidé, to speak figuratively, of computer programs.) 

The LDOS system does come with its own disk operating system built into ROM 
(EPROM actuallly, on the interface board). So it can be used just as it arrives 
with its commands of SAVE and LOAD of BASIC programs, DELETE, FORMAT and DIRECTORY. 
However much more experimentation is possible with this little computer when | 
equipped with an LDOS disk system, You can do everything from writing your own | 
command system, using disk operation commands that you have invented in syntax and | 
name all yourself and do it within your own BASIC programs, with only a few days 
of programming work (if you are used to BASIC programming) to manipulating data 
on disk down to very primitive machine code call and floppy disk track-by-track 
level. Yes, tne LDOS system is open enough to aiiow you to write your own “disk” 
routines as utilities, extensions of the LDOS command set or even as a whole new 
disk operating system, all without touching the innards of the electronics of 
that hardware, This is what concerns us in this chapter, 

This chapter covers the fundamental principles of ZX-81/ TS1000 programming tha 
can be used to write your own programs to extend the usefulness, command structure 
or other features of disk system use to your own ends; It starts with simple 
routines that you can add to any program you have written and keep using only 
BASIC programming. It ends with more and more fundamental and low-level calls, 
data structuring and other explanations of the art and science of disk operating 
system design, Lots of sample routines, mainly in BASIC are furnished, lots of | 
raw ideas to exploit on your own and lots of technical wisdom passed on character- 
ize this chapter and make it interesting for the technical enthusiast, Used in 
combination with other documentation and materials in this book it can truly 
Serve as a ticket to many hours of exploring that little accessed field of the | 
hobby, education in systems inherent to the computer like DOS, disk function, | 
Storage layout in RAM, within BASIC and on disk tracks, 

Take a specific example first, Every time you want to do something with the | 
disk system, when you are writing a program you need to type in PRINT USR 14336 | 
to get to the command screen, to see for example a disk directory (contents of a | 
disk inserted in the drive) and further type the DIRE (at least) on that screen, 

By putting LET DIRE=VAL"9200" in your program and running it so that it gets into 
he variable table, and further putting a little routine in your program, the few 
ines below: i 


ae 


gone REM VIEW DISK CONTENTS -— — 
10 CIS = P 
9220 PRINT USR 14336 QOO MEN Bell Leo dd 
9230 REM DIRE : 
299 STOP rout. is to be used 
9299 in a running prog. 
will help you to speed up that process, When such a program is in your ZX-81/ 
TS1000, the simple command (given the running of the program has halted), 
GOTO DIRE, while bring you the directory of the current disk, With this simple 
addition to every BASIC program you write (or have typed in from a magazine or 
book) you have started in adapting LDOS, making use of its simple interface with 
the BASIC built into the ZX-81/TS1000 computer, to suit your own convenience and 
add to its ease of use, Could anything be easier for the BASIC programmer? If | 
this is too easy, read on for some truly amazing potential projects that you can | 
perform as experiments in rewriting the LDOS disk commands and features, nearly | 
always in BASIC rather than machine language! 


POKE of LDOS Commands And File Names To CLINE — A Demo pe daz f 
This listing.is a demo of certain routines that may be useful to adapt. The 
routines includea simple syntax checker for file names and an LDOS emulation in 
BASIC of LDOS commandssyntax checking/acceptance of command types.allowed, It 
only handles BASIC files with the extension .B-, where the'-'must be a number, 
The DIRE, FORMAT and DELETE commands are not really useful, since on running one 
throughnthis routine, you are left in LDOS screen mode (without any heading to 
say you are in LDOS screen mode),aadüdyou cannot get back to the program from 
there, except manually. This is due to the way the LDOS handles these commands, 


100'. REM. Subroutine to Poke commands from running program to GLINE to get 
LDOS functionsz?from a running BASIC program (rather than POKE to 
a REM statement after RAND USR 14336 in a program, see page ll- ) 
101 REM ENTER LDOS DISK A@CESS COMMAND FROM KEYBORRD (Without file name) 
105 PRINT"ENTER DISK ACTION COMMAND" 
110 INPUT A$ 
lll CLS 
112 IF A$="" OR A$s"EXIT" THEN RETURN (exits if nothing entered or EXIT) 
113 IF 4>LEN A$ THEN GOTO 380 
115 IF A$% LOAD" AND A$<>"SAVE" AND A$(1"TO:.4)<? "DELE" THEN GOTO 300 
119 REM ENTER FILE NAME AND CHECK IT 
120 GOTO 135 
130 PRINT N$,,"(LDOS PROG.FILE NAME MUST HAVE 6 CHARS .MAX.+DOT+B+NO.)...REDO" 
135 PRINT"ENTER FILE NAME" 
140 INPUT N$: 
145 CLS 
150 IF N$="" THEN GOTO 130 
160 LET NL=LEN N$ 
170 IF NL«4 OR NID? 9 THEN GOTO..130 
180 IF N$(NL-2)€»"." OR CODE(N$(NL))€28 OR CODE (N$(NL))s 37 THEN GOTO 130 
. 189 REM NOTE THIS ROUTINE COVERS FILES THAT ARE BASIC PROGRAMS ONLY > 
190 IF N$(NL-1)«»"B" THEN GOTO 130 
300 REM CHECK LDOS COMMAND FURTHER AND SET UP FOR POKE 
310 IF A$«»"LOAD" AND A$«4»"SAVE" AND A$(1°TO L)c»"DELE" THEN GOTO 350 
330 LET C$sA$(1 TO 4)+CHR$ 11 + NË + CHR$ 11 
333 REM THIS LAST LINE TAKES THE COMMAND IN A$, TRUNCATES IT TO THE lj CHAR. 
aa LDOS ALLOWED SHORT FORM AND ADDS A QUOTE THEN ADDS THE FILE NAME IN N$ AND 
TEEN ADDS A FINAL QUOTE / THIS MEANS C$ CONTAINS THE COMMAND TO BE POKED INTO 
CLINE, IF IT HAS A FILE NAME - IF IT IS DIRE, ETC; LINE 360 DOES IT INSTEAD 
34,0 GOTO 400 
350 IF A$(1 TO 4)<>"DIRE" AND A$(1 TO 4)<>"FORM" THEN GOTO 380 
360 LET £$=A$(1 TO 4) 
370 GOTO 400 
379 REM ILLEGAL NAME ERROR MESSAGE 
380 PRINT"DISK ACTION NAME ";A$;" NOT ALLOWED, USE ONLY LOAD,S 


390 GOTO 100 

400 REM ROUTINE TO POKE C$, THE FULL LDOS COMMAND — IN TO CLINE AREA IN LDOS RAM 

410 POKE 12291,¢ 

411 REM THIS CLEARS LDOS ERROR FLAG 

420 FOR N=1 TO LEN C$ 

430 POKE 12315+N,CODE C$(N) 

431 REM 12316 IS FIRST ADDRESS OF CLINE AREA, A TEMPORARY VARIABLE/SCRATCHPAD 

AREA WHICH WILL BE OVERWRITTEN PARTLY DURING FILE SAVE, ETC. OF LDOS 

440 NEXT N 

450 RAND USR 14480 

2$,50«SLOW 

490 RETURN 

499 REM THIS RETURN WILL NOT BE EXECUTED AND PROGRAM WILL TERMINATE WITH LDOS 
M/C RUNNING IN LOOP TO EDIT'LDOS COMMAND AND ENTER NEW ONE (LDOS COMMAND 
SCREEN) FOR COMMANDS FORMAT, DELETE AND DIRECTORY BUT ROUTINE WILL RETURN 
CONTROL TO BASIC PROGRAM AFTER THE GOSUB CALLING THIS ROUTINE FOR SAVE OR . 
ce EXIT; MAKING THE ROUTINE AS IT IS HERE USEFUL MAINLY FOR SAVE AND 

call it from a BASIC program line like 1000 GOSUB IO0 in your program 


e 


Editing LDOS Commands Inside Your Own Programs: Utilities, Alternative DOS 


When you are writing an alternative operating system, utility or part of an 
application program, you may want it to include a disk operation, usually a SAVE or 
LOAD to/from disk, You can use the operating system primitives in the LDOS ROM to 
do the complicated work but you need to get a command to the LDOS system to act on 
The simplest way of doing that, discussed already, is to use a simple command or ° 
part of a routine to pass an LDOS command of a fixed, predetermined type from BASIC 
to LDOS, as in the previous examples on page 4-3, roughly as follows: 


7000 REM LDOS COMMAND PASSED FROM RUNNING BASIC PROG. TO i 
7010 INPUT L$ b E 
7020 IF L$zs"" OR L$s"EXIT" THEN RETURN 

7030 IF L$="SAVE-IT" THEN GOTO 7500 

7050 GOTO 7000 

7500 RAND USR 14336 

7520 REM SAVE"IT-PRG. BO" 

7599 RETURN 


This is certainly simple but the problem is that only one response is possible, 
for example running the:»es command, SAVE"IT-PRG,.BO", What if you want to LOAD some 
data from an array? If the array name is always the same, you could add to the 
above, line 7040 IF Lh="DATA+GET" THEN GOTO 7600, and at 7600 you have the routine 


7600 REM LDOS ROUTINE TO GET DATA FROM ARRAY SAVE 
7610 RAND USR 14336 

7620 REM LOAD"D$IT.AQ" 

7630 RETURN 


Again, this is all right unless you want to load a different array, or file 
name, Then you will want to have a routine that allows the user in a program that 
is running, to enter the file name, Then, using this method, you have to get that 
file name into LDOS, It can be poked into the REM statement used in the above 
examples, character-by-character, (Note that you must leave enough extra spaces 
in the REM to be POKEd to avoid POKEs in either the next line or the last character 
of the REM line which is ENTER/NEW-LINE, poking of which will cause a break in the 
LIST of the programt) On the next page is a routine that does just that, with an 
INKEY$ instead of the INPUT it puts anything you want into a REM statement that 
can be called, after a RAND USR VAL"14,336" statement to trigger LDOS. It uses a 
trick to find the address for machine code (address in memory map, in base 10) of 
the next line of BASIC. Then simply adding a number to that (such as 28) will 
allow for the BASIC statements that follow that, until the start of the point that 
you need in the REM statement to be POKEd. Please note that you can't change any 
of the BASIC lines after the PEEK until the REM, even by adding or deleting one 
letter, number or making any other change if the number 28 is still to represent 
the length in bytes between the PEEK line and the REM line (in the program next)! 

This little subroutine uses a trick of tapping the NXTLIN system variable of 
the ZX-81/TS1000 which is updated after each line to reflect the address of the 
next line after that to be executed, It simply PEEKs the 2-bytes of this system 
variable that. gives the 16-bit m/c address of the next line. The listing on the 
next page of the whole routine is fairly self-explanatory otherwise, It is also 
a handy routine to use for making your own programming language interpreter and 
a lot of other things and comes in two versions (see line 4555 in it), the second 
obtained rather simply from the version show, by making the few changes mentioned 
in that REM statement. This use of 5 instead of lO as listed allows a whole REM 
statement to be edited/entered. Using the revised version with 10, would allow 
only the file name (after for example LOAD" ) to be edited. Multiple use of 
this REM edit routine at different parts of the program could be used to edit, 
SAVE", LOAD" or DELE" — commands for LDOS, freeing you to use other words or eve 
a menu choice system for SAVE, LOAD and DELE, Note before you use the listing nex 
page that a better system of pre-checking the commands to see if they are legiti- 
mate LDOS commands and hanging up the program, are also needed, other than the 
primitive rejecting any command containing a character with ZX-81/ TS1000 character 
CODE greater than Z (line 4620). 

Even if you never use this method reading the LISTing next page is educationa. 
since it is a fairly accurate rendering of the LDOS command line edit routine whicl 
is of course not in easy to read BASIC but in machine code, 


D ROUTINE 4 p. 
Mee erus that works much like the m/c LDOS editor for 


entering an LDOS command line, If you were to put in your program GOSUB 

4400 this routine would allow you to enter a BASIC line such as an LDOS 
command, as necessary to get it in as a disk command after that RAND USR 14336 
call for LDOS, GOSUB 4545 would then make this call, although you would 

want your program also to do some checking as to the correctness of the com- 
mand before turning it over to LDOS, an error then resulting in the 'real'! 
LDOS screen being activated, This shows you roughly how the LDOS screen edit 
for LDOS command line works as well. 


4400 REM THIS INITILIZATION IS NEEDED IN YOUR PROGRAM SOMEWHERE (LINES 41400-4490) 
4410 SLOW 

4490 LET Y= 

4500 REM START OF ACTUAL EDIT. ROUTINE TO MODIFY REM LINE 4550 

4505 IF Y>19 OR Y< Ø THEN LET Y=ø 


4510 PRINT AT Y,g;" "SAT Y41,0;"«"; 4511 REM PRINT » PROMPT 
4515 LET X$z'"" (4517 LET A$z" " 4518 REM 19SPC,SEEL65Q 
4520 LET N25 4525 REM lines next must not change 


4530 LET NA#28+PEEK 16425«256«PEEK 16426 
4540 GOTO VAL" 4560" 
4545 RAND USR VAL'"14336" 
4550 REM (note that a lot of spaces here) 
4555 REM CHANGE N IN LINE 4520 TO 10 AND ALL OTHER OCCURRENCES OF $TO 10 IF 
THIS ROUTINE TO START WITH FIRST 5 CHARS. IN REM AT $550 SET TO FOR EXAMPLE 
PERMANENTLY TO SOMETHING, LIKE LOÁD" AND ALSO MAY WANT TO CHANGE 19 IN LINE 
4620 TO 18 IF YOU DO THIS 
4557 RETURN 1558 REM RETURN FOR RAND USR 14336 CALL see top 
4560 LET X=¢ 
4570 LET X$sINKEY$ 
4580 IF X$="" THEN GOTO 4570 
4590 LET X=CODE X$ 
4595 IF Xz119 AND N»5 THEN PRINT AT Y41,(N+1-1-5) ;CHR$(128+PEEK (NA«N)) 
4596 REM THAT LINE WILL INVERT ON BACKSPACE LIKE LDOS--WHICH IS A BIT CRUDE, 
BACKSPACESRUBOUT OR DELETE ON ZX-81/ TS1000 KEYBOARD, remove -1 AFTER 
N IF YOU DO NOT USE A PROMPT LIKE THE * USED HERE AT BEGINNING CMD LINE 
FOR EXAMPLE, ALTHO OTHER CHANGES NEEDED IN CODE TO DO THAT TOO 
4600 IF X=119 AND N»5 THEN LET NeN-1 4601 REM BACKSPACE POSITION IN LINE 
4610 IF X=119 THEN GOTO 4560 4611 REM MAKES NOT ENTRY OR CHANGE IN INPUT 
4620 IF N»19 OR X263 OR Y>20 THEN GOTO 4698 4621 REM IF X» 63 catches ENTER-N/ L 
4622 REM IF X563 IS ALSO A CRUDE ERROR REJECTOR, Y»20 IS NOT GOOD FOR BOT.SCRN. 
4630 PRINT AT Y«1,(N*1-5);x$ 4631 REM REMOVE THE 1 IF REV., See 1555,PRMH 
4635 REM THIS IS THE PRINT THAT PUTS THE CHARACTER KEYED-IN ON SCRN.,(ECHOS iT) 
461.0 POKE NA+N,X 
4645 REM THIS POKES THE CODE INTO THE REM STATEMENT ON LINE $$50 
(4650 LET A$(N TO N)=X$ 4655 REM THIS MIGHT BE USED TO PUT THE COMMAND INTO 
A STRING A$ SO THAT IT COULD BE ANALYSED/PARSED-ERROR CHECKED ELSEWHERE, 
SEE ALSO LINE 4517 ABOVE) 


4660 LET N=N+1 4661 REM MOVES POSITION POINTER, CMD, STRING/LINE FWD. 
4670 GOTO 4560 
4698 LET Y=Y+2 4697 REM INCREMENTS PRINT LINE LIKE LDOS SCROLLING 


4699 RETURN 4700 REM THIS ENDS EDIT ROUTINE CALLED AS SUBROUTINE TO EDIT 1 LINE 


This has been typed from a tested program with some elaboration, mainly 
extra REM statements to clarify its operation principles, Use of a routine like 
this will help in putting LDOS commands into a running program and as a bonus 
listing it gives the reader a hint as to the Steps that the LDOS line editor for 
LDOS CLINE (command line) goes through, The LDOS CLINE editor is in m/c though, 

A routine like this could be used to build a utility program for use with 
LDOS or a BASIC or part-BASIC operating system shell, etc. A few lines added 
to translate from a completely different command language into LDOS command 
language, poked into the REM statement is another approach to this, so that 
COPY could be translated into two LDOS commands, LOAD"---name of file, and 
SAVE"---name of file, emulating CP/M or MS DOS Style of command language! 


Writing Utilities Or Operating System Extensions In Other Languages De 


To really use another computer language than the built-in BASIC of the ZX-81/ 
TS1000 you will need more than the simple adaptation to load it in from disk that 
is dealt with in the chapter on converting commercial programs including compilers 
to disk, For this you will have to save data from the program to disk and load 
data from disk into the programs, This involves using the facility in all program- 
ming languages to use a machine code subroutine inside the higher level language 
part of the program, The Larken LDOS user manual offers some of the technical 
information on the machine code calls needed, to do for example a code save or load 
from a machine language program, 

If the ZX-81/TS1000 built-in BASIC is well documented, easy to program in and 
LDOS already has been designed to make use of saving data residing inside a ZX-81/ 
TS1000 built-in BASIC program, why use another language? Well, the built-in BASIC 
may be simply too slow to process for example text, one or fewer characters per 
pass, The compiled languages on the other hand do in seconds what a ZX-81/TS1000 
built-in BASIC program may do in one or more minutes, What kind of opportunities 
are we talking about when it comes to utilities to use with LDOS that need speed? 


A text editin rogram may need search and replace and other 
routines that are too complicated to.write with all their 
features needed in machine language, so a higher level 
language is needed to speed them up. FORTH is a fast editor, 


Data compression programs such as the diatom pack routine 
described in the book by Held, "Data Compression", Publ. 
John Wiley, proceed through the text, two passes per 
character to look for common two letter combinations to 
compress into a single byte. This runs too slow to do 
in the ZX-81/TS1000 BASIC as do many other data compression 
routined, 


Printer Driving Utilities may be needed for programs that 
require ASCII output and perhaps control codes added or 
Stripped away, if a full sized printer interface is fitted 
to your ZX-81/TS1000. Again, character by character proc- 
essing of a long text will run tediously slowly in ZX-81/TS1000 
BASIC, FORTH also is made to handle charcaters in ASCII 
internally itself, ZX-81/TS1000 uses internally a non-ASCII 
character code whiéh may require a lot of churning to convert 
to ASCII for printer use if thescode conversion program is 
written in ZX-81/TS1000 BASIC, Hardware code conversions may 
be not available at all or only convert part of the alphabet, 
requiring a utility to prescan or do a final edit on the text 
being converted to ASCII, 


Foreign Accented text can be handled easily by most word proc- 
essors using the trick of putting a < sign ahead of a character 
which is to have an acute accent and a > sign ahead of a 
character which is to have a grave accent over it and a »» 
(ZX-81/TS1000 CODE, double asterisk in one chracter) before 
a character in French which is to have a circumflex or one 
in Spanish (the n of Séhor) that needs a tilde over it. To 
print out such text with a full scale dot matrix printer 
requires that a program , basically a utility, scan the text 
for all such special character pairs and convert them to the 
appropriate single-byte codes for the accented letter needed 
(IBM compatible printers use a number of codes over 128). 

For such a utility or printer driver, you need to look at 
each pair of characters, making two passes per character in 
effect, through the text, This is excruciatingly slow in 

the built-in BASIC, so that using a faster high level language 
again offers a solution, for writing such a program, (Note 
that this writer has written a couple of such accent programs 
in BASIC for the IBM PC to test the concept.) 


pe 
Writing Utilities In Other Languages Continued 


Capitals and lower case is the standard way to output text ona. 

~ Standard printer but the ZX-81/ TS1000 normally uses just capital 
letters, the only ones supported in its unique Sinclair character 
code, To scan the text and convert all letters to lower case 
except those that are in a special context, such as at the 
beginning of a sentence or marked by the typist by having a 
period and a space placed right after them, whic.h are to be 
kept in capital letter form, takes a lot of text processing 
and again would be too slow in ZX-81/ TS1000 BASIC, The . 
solution again is to write such a printer driver or text 
conversión utility in another, faster higher level language. 


The higher level languages available for the ZX-81/TS1000 are well suited for 
writing such utilities as far as spedd is concerned and also in that the limitat- 
ions of.such programs in not having floating point arithmetic is irrelevant to 
such text writing programs. Other than games, such utilities offer the best 
possible showcase for such integer number only programming languages, The dis- 
adavantages however are that many of these languages have awkward limitations on 
string handling that must be taken into account in writing these-utilities, for 
example, Partial Pascal olny allowing (as in most Pascal dialects) single dimension 
chara ter arrays, in other words, just long strings, and MCODER BASIC limited to 
a fixed string length of 32 characters or less and not having string array capab- 
ility and FORTH using its own block structure for handling text, For this reason 
the utilities are probably best written as drivers, outputting and inputting dir- 
ectly between the printer and/or blocks/tracks on the disk, rather than trying to 
load a whole array saved mass. of text in string form, and try an shoehorn it in 
to limited RAM and the quite differently structured data handling formats of any of 
these compilers, Second problem is the lack of documentation of the internals of 
the compilers, meaning that you have to be careful in writing your machine code 
routines, for it is machine code subroutines called from within these higher level 
compiled languages which is the natural way to get them to work with LDOS disks, 

Even a compiled BASIC like MCODER can not use the normal BASIC entry to LDOS, 
since the source code REM line will likely be deleted in MCODER BASIC and the 
ZX-81/ TS1000 System variables tampered with and the location of the REM statement 
(coming after the RAND USR 14336) will not likely be anywhere near where the LDOS 
program is going to look for it (even if the source code is specially left in the 
MCODER program), In fact the MCODER machine code for the run time module comes 
first in the RAM usually (default loading position) so that the LDOS would start 
looking for such a REM statement right in the middle of this code, It is a moot 
point if even a patient machine code hacker could figure out where to put a pseudo- 
machine code REM statement in the program so that LDOS could find it. Not to be 
ruled out, but not a general solution to the problem of LDOS interface, and 
certainly not to be solved by simply using the RAND USR and-REM statement in the 
program, the same way it is used in a program in the ZX-81/TS1000's built-in BASIC, 

Given that machine code subroutines are necessary to get disk access and that 


nals of the programming languages in question, a few points are to be mentioned to 
Show the machine code programmer what to look out for in the course of the m/c 
routine writing. The possibilities for bugs must be explored by doing some reverse- 
engineering and writing your own documentation of the internals of the programming 
language that you intend to use for your utility, 

Some clues about this can be obtained by looking at the documentation that comes 
with the programming languages, We take a look at some of this for the common 
higher level langusges that are on hand, Artie FORTH, MCODER BASIC compiler and 
Partial Pascal, These were widely enough sold that they are probably the commonest 


Machine Code Subroutines For High Level Languages pe 


The thing is that most high level language designers, those who implemented 
BASIC, Pascal, FORTH, etc, languages for the ZX-81/ TS1000, anticipated that the 
user might want to do things that the language normally does not allow or do it 
faster, and for that reason want to include a machine language subroutine to do it, 
inside a program the rest of whihc is written in the higher level language, BASIC, 
FORTH, whatever, There are two big problems with this. The first is that the 
machine language subroutine is often limited in length or other specifications to 
the point where very little can be accomplished, The second one, the main one, is 
that the languages themselves are usually so insufficiently documented that the 
knowledge needed to mesh your machine language routine with the programming lang- 
uage's internal structure is practically never given in the users manual or typical- 
ly anywhere else, That means that the users desire to do something in machine 
language is highly limited, limited to the sort of routine that does not perhaps 
need much or any knowledge of the internal structure of the programming language 
software, such as merely doing a short arithmetic calculation in machine language, 
for integer arithmetic, or moving the program source code to an external I/O buffer 
like a modem or disk drive buffer, and calling the m/c routines in the external 
device's ROM to handle it from there, This latter is not a totally hassle-free ` 
or simple task in itself, but about at the limit of the patience for most m/c prog- 
rammers in dealing with the frustration of trying to reverse engineer the program- 
ing language software from scratch, something that is only done commercially in 
cases of true desperation since it is so time consuming and error prone, 

The most obvious case of adding a machine code subroutine and the only reason- 
ably well documented, if not ideally properly documented high level language to add 
it to, is the ZX-81/ TS1000 built-in BASIC itself. The following assumes some 
mastery of this field, or you would not be interested in reading this far in this 
article anyway. It gives some things you must find out about the other language. 

Some questions arise in adding a machine code subroutine: 

l)maximum length allowed for your m/c routine (none in ZX-81/ TS1000 BASIC-ROM) 

2)registers and RAM to avoid using in order to avoid crashing or interfering 

with either the ZX-81/TS1000 operating system or the programming language 

(the ZX-81/TS1000 operating system seems sensitive to use of the prime 

registers, although not all of them, and the index registers, for example) 

-using RAM within the machine code subroutine, such as a few bytes preced- 
ed by a JR, jump relative to jump over them, is the safest approach, 
although it may be written in a way that assumes that this location is 
not moved around in memory (the machine code routine with the gap for 
temporary storage, which may not be true) 

-certain favourite hiding places for data, parameters in RAM may or may 
not be available, or already used by some program or routine, if you 
have extra RAM somewhere, with a Hunter or SCRAM board, CMOS RAM or 
a 64K RAM pack, these offer some places, specific to your set-up however 
making your program non-portable and non-usable. by others typically 

-certain hiding places in the ZX-81 itself, like the system variable 32 

at 16507 or the printer buffer 16444-10416475, Sl at 16417, etc, 

although take care that these are not erased unexpectedly by the 

ZX-81/TS1000 operating system 

3) some programming languages require a special termination of a m/c program, 

while others do not. The ZX-81/TS1000 built-in BASIC does need at 
least a return, like C9, unconditional RET from subroutine, while the 
IBM PC's GWBASIC does not need that and may crash if it is used, Also 
the full, approved termination for the ZX-81/TS1000 BASIC is not merely 
C9,hex, which usually works, but 3E,lE,ED,A47,FD,21,00,40,C9 hex if you 
consult the best reference works, Each language has its peculiarities 
in this respect in addition, 

lL)The way of passing a parameter, too the machine code subroutine and also 

from the machine code subroutine back to the high level language. 

ZX-81/TS1000 built-in BASIC does this with a LET X=USR 16514 if indeed 

16514, (the first spot in the first REM statement) is where the machine 

code routine you are calling is located, otherwise another address 

would be quoted in USR., This puts the contents of the BC register at 

time of mc routine end, into variable X in BASIC, Parameters are 

usually passed the other way, to the m/c with a POKE, in BASIC, 


Machine Code Subroutines Continued Pe 


In Partial Pascal, PEEK and POKE are allowed but under the name MEM 
and with a different syntax, There zre also extra ways to pass 
parameters using the machine code subroutine call itself, USR, in 
Partial Pascal, making it well supported for machine code use, 


MCODER, the integer BASIC compiler allows the USR command just as in 
the built-in ZX-81/TS1000 BASIC. You can locate the machine code in 
the MCODER BASIC program in 1 REM, a REM statement in line one, and 
it will be called by a USR 20498 (something that outs the entry 
point. for the compiled program at a different location than the 
normal, non-m/c containing program's 20500 address, 


Artic FORTH allows machine code subroutines to be inserted into 
FORTH programs although the syntax and method is not much explained 
in the Artic. FORTH user manual, the user having to make use of a 
standard reference book on FORTH for a full explanation. An example 
of a machine code implementation of PLOT/UNPLOT is given on page 37 
of the user manual as follows: 

:PIT 4030 C! ;CODE ELC DIC, C5 C, LB C, 45 C, CD C, BB2 , Cl gs 

C3 C, NEXT , 


The C coming after each m/c hex code number stores one byte 
into the RAM address where PIT will be able to call the 
machine code, CODE; is an invocation of the assembler, 

a true assembler not furnished with Artic FORTH, and so 

it is assumed, this just passes already hand assembled code 
into FORTH and there is no return from subroutine, but NEXT 
indicates to FORTH that the subroutine is to be returned from 
and normal FORTH execution resumed, 


Most languages should allow calling ZX-81/TS1000 ROM routines, at 
least the more primitive ones, although they may also substitute their 
own calls, as with FORTH by Artic, that uses ASCII, avoid m/o 1/0. Use 
FORTH primitive # etc., instead of m/c call, for output, TYPE, EMIT, LIST 
and so on,INKEY$ with KEY and INPUT with QUERY, so that FORTI rather 
than n/c calls do.all std, I/0. If m/c calls were used they would 
respond in ZX-81/TS1000 CODE rather than ASCII, perhaps getting things 
really confused, FORTH it should be noted has a general and a machine 
stack, the general stack the one typically refered to, All in all, 
FORTH is for FORTH hackers willing to explore technicalities to use it. 
Just remember in summa primitive calls are done by FORTH name, either 
standard or custom written by the user, in FORTH. 

5)Stack use is important as is the use of system variables, and m/c calls 
that are unique to the complied language. If you are not aware of 
stack use, the compiler may clobber data-you-put in the stack or the 
limit of size of stack may be exceeded if your m/c routine uses it 
too much, Any m/c calls inside your t/c may clobber your stack ór'reg,use 


Artic FORTH uses certain FORTH words virtually as programming language 
System,variables, so you may wish to examine the defintions of such 
words ss BIK, csP, CONTEXT, HLD, LATEST, OUT, SCR, TIE, VOC-LINK, and 
WARNING, all these system variables having names to access them with 
just like the names to access primitive calls, explained above, 4). 


Pascal has a limit to stack use by user added m/c of 50 bytes. Some 
register use restrictions are also laid out, Little or now clue of 
internal systems variables or m/c calls is given in the manual,for 
Partial Pascal, 


MCODER mentions a few user calls in its short manual and some system 
variables that work much as calls and system variable access works in 
normal ZX-81/TS1000 BASIC, RAND USR 17287 asks CODE? and you can 
specify the entry address to compile the MCODER program to, RAND USR 
17281 will delete your source code. POKE 16417,n, will cause the 
screen to scroll n times (lines). 


DOSDOC.BU Test Drive Of This Software Pe 


DOSDOC is a program written by P, Mullen, version 1,04 is the one being tested, 
dated Aug.,86, although a version 2 is also circulating, DOSDOC.Bl, 1987, 


With some disk ;roblems, some of the limitations of LDOS become more obvious, such 
as the elimination of a time-out routine to suspend disk operations after a 
certain elapsed time, If there is a drive unit problem or a disk problem, the 
drive may rotate via hub motor forever, when an optionrof DOSDOC.BU is selected 
to read to the disk, since it relies on the m/c low-level routines in LDOS and 
simply calls them one by one from BASIC instead of going through the editor/ 
monitor routine as done for nórmal disk operations in LDOS, operations that do 
not include what DOSDOC sets out to do. 


A bad disk from which programs cannot be loaded off anymore is 
inserted into disk drive, DOSDOC run and option A, examine/ change 
data on disk track by track is chosen, (after bad-block option 
turned up no bad blocks, via CRC checkj. 


This causes certain m/c routines in LDOS to be called by BASIC: 


POKE 12289, TRA CKNO REM TRACKNO g to 79,3001hex,LDOS R4 
FAST . sys var curtrk 

RAND USR 14778 REM call settrk LDOS subrt.39BAhex 
RAND USR 14546 REM eall leadbuffer off disk, 38D2he 


...nOow you have the contents of that track in 2K RAM buffer- 
from address 12352 which is set at 255 -start header 
of track, on a data track 1-79, start of directory on 
track Ø, directory track (oniy] which has no header 
-12353 contains the track number (0-79) in hex, although PEEK 
will get it and convert it into normal base ten 
-PEEK commands in a FOR..NEXT loop will in FOSDOC display 
all these both as a base-ten number and do CHR$ to see 
what it might be if used as a token or alphabetic characte 
according to ZX alphanumeric code 


A:loop like the following might do that a little faster than the DOSDOC one— 
GOSUB 10 


put in from line 10, the following:- 


10 FOR Xs TO 1984 

20 A=12352+X 

30 CXPEEK A 

LO PRINT ACP" CHR C, 

50 NEXT X 

60 RETURN 

65 REM PRESS CONT WHEN SCREEN FILLED TO GO ON FURTHER- 

66 REM ADD OPTIONAL LINE 35 IF X« 23 AND TRACHNOoQ THEN 
PRINT "HEADER PARAMS. "; 


On observing track zero, notice that address 12353 in RAM buffer contains 79, 
while it should contain g, for track zero, Maybe this is the problem; and 
since it would not result in a CRC error, the reason why the CRC check turned 
no problem, So press A for alter when bottom of page is reached and key in 
Address, 12353, number/insert, Ø, The press S to save buffer back on disk, 


now in corrected . This is done in DOSDOC.via BASIC, 
RAND USR 14778 REM settrk to TRACKNO POKED into 
12289 previously 
Bate nu REM get hub motor spinning, this 
RAND USR 16374 FOR-NEXT loop number will vary 
FOR I=1 TO 30 depending on where loop is 
NEXT I in beginning or here, end of 
T -buf a fairly long program 

nens mo Et E 123002300Chex-errct in LDOS sys va 


temp area of RAM buff. , 
(see LDOS manual by Larken, p.6 -outport... here for port #69-disk drive, 8 writ 


DOSDOC Session Continued ... pe 


Now try disk again...result, directory contains garbage now, does not even look 
right now, On further analysis, file analysis, it seems track zero really did 
contain track 79 data, or it sure does now, That means that the whole directory 
track would have to be reconstructed, a many hlur job, byte-by-byte using DOSDOC, 
if not a week or two long job! This means that the alternative would be to try 
and get just your fa vourite files off the disk and transferred to another disk, 
track by track, again rather tedious, Maybe now is the time to file that disk in 
the rainy-day, things to do file, and get on with something more useful. But now 
we know that having the directory track replaced with a copy of track 79, by some 
freak of disk malfunction, was what screwed up the disk and made it unreadable. 

This is the reason demonstrated, why a simple file recovery utility that is 
completely automatic likely will never exist for any system, and certainly would 
have to consist of a series of file recovery utilities for a small RAM computer 
like the TS, since the size of program would be too big for one program to fit in 
a small computer. It would have to be just that complicated. 

The DOSDOC is the only serious attempt to write a file recovery program for 
the LDOS, ZX-81/TS1000 system, and so it is the best available. There seems to be 
a problem.with the version that this writer tested in that to enter the address 
to change, you are going to have a problem with the INKEY$ loop used if you make 
a mistake, something easy to do, and try to rub-out it with destructive backspace, 
which simply means that using INPUT would have served better inthis case although 
INKEY$ looks fancier, Entering more than one character with an INKEY$ routine 
just does not work well with the ZX-81/TS1000, and this writer has outlined .. 
elsewhere, how a custom INKEY$ or INPUT routine might be written as a m/c subroutin 
to get over these deficiencies, something that Larken Electronics did for the LDOS 
command/monitor, for example, to overcome just that problem type. 


e€e606006009902»00€099909^09 


DOSDOC options as seen on menu: l-Tracks Used/Free 
(plus elaboration) 2-Bytes Used/Free (Calculated from above) 
3-File Analysis (loads tracks, bypassing 
CRC error which in LDOS causes non-load) 
l-Examine/Modify Track (9-79, one at a time) 
5-Check Badblocks (Using CRC apparently: good 
mainly for media error/damage, not 
foolprooof for all types of errors) 
6-Copy Disk (2 Drives-only, need two drive 
system to do this) 
7-Format Disk (Simply calls LDOS FORMAT from 
BASIC command in this program, in REM) 
-Next Disk (Options 1 - 3 above, try them on 
another disk) 
9-Exit DOSDOC (to BASIC or LDOS command screer 
at your option) 
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Chart > # 0 , Hardware : p.7-00 
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Intelligence and complicated algorithms, track assignment and directory 
block allocation housekeeping and record keeping is all handled by 
the ZX-81/TS1000's Z-8O0,microproéessor running m/c from the 2K ROM 
on the interface board, using the 8-line data and 16-line address 
bus of the Z-80 for instruction acquisition (m/c) and data transfer 
to the scratchpad/ systems variable part of the 2K RAM buffer on the 
LDOS interface board. 


The LDOS command interpretation shell is all on the LDOS 2K ROM and uses 
no special RAM'areas or ZX-81/ TS1000 system variables (that it might 
overwrite-except that the ROM and RAM are mapped into the higher 4K 
of the gap in the memory map of the ZX-81/TS1000 from 8K to 16K, beyond 
its own ROM with its BASIC and before the ZX-81/TS1000 RAM -1K, 2K, 16K 
with a standard RAM pack, 32K with a d ni RAM pack - and conflicting 
with some of the memory mapping of some 64K RAM packs). 


Block transfers using m/c routines in the LDOS operating system ROM 
are used to form up track-fulls of data in the 2K RAM (using 1960 bytes 
of it for data) but the actual serial transmission (at 125 KHz baud ratd 
to and from the disk drive is via integrated circuit hardware on the 
interface board rather than a decicated floppy disk controller chip. 
The main part of this is the 6850 serial-paralle conversion and data 
send-receive chip, whose in and out registers are accessed via Z-80 
IN and OUT by a port m/c instructions, 


Control messages and disk status messages, including the signals to turn 
on the disk drive hub motor and spin the disk and move the head to a 
different track are transmitted using the IN and OUT instructions of 
the Z-80 to transmit these control signals (and receive them) via 
certain port addresses (of the Z-80 address bus). 


Analogue to,digital conversion and the record/write head driver circuits 
and read/play head senso amplifiers, are all on the 54 inch IBM-comp- 
atible disk drive which comes with its own p.c.b. with these electronic 
functions and the necessary components for carrying them out, 


-Case, disk drive power supply (usually 12 and 5 volts) and LDOS interface 
psc,b,power (5 volts) are extra to that provided with the basic LDOS inter- 
face board and must be provided by or constructed by the user or someone 
prepared to sell these items, Plans for the power supply that could be built 
for this are provided in the original Larken Electronics documentation for 
the interface board, 


Note: for the corresponding software (DOS LEVELS ....) see p, 6-3i 
and the meshing; of the hardware and software will be even 
more obgious, 


The 9602* Dual Retriggerable Monostable As A Data Separator/Synchronizer E 

The single-density floppy disk encoding system of LDOS uses a digital version 
of FM, called by an English magazine, pseudo-FM, to be proper, but by most dan the 
field just FM as opposed to the MFM of à double-density system used by IBM PC's, 
The analogue/digital conversion circuits on a pcboard mounted in (and sold with) 
every IBM compatible, DSDD-style, disk drive has already processed the signal that 
the read head has picked up from the floppy disk as it rotates, and it outputs a 
TTL compatible pulse, +5 volts. The 9602's job, with it passive circuitry that is 
simply a filter, is needed since the 8-bit data stream going to form a byte in 
what would in any other system be a floppy disk controller chip (but here is the 
6850) is within thelO-bit burst, an asynchronous pulse stream going to a synchron- 
ous receiver, within the pulse it must be synchronized, to tell where the dividine 
lines or timing frames for each bit of the eight lie. For this you need a clock 
pulse. How to get a clock pulse out of the data stream of l0-bits, when it does 
have a certain rhythm even if it misses a beat during a sequence of repeated pulse 
from the rhythm of the pulse stream itself? The result of solving this question 
is a data synchronizer so the bit stream can be separated into a clock and a data 
part, the clock being the rhythm and the data being whether a high is sent on each 
drum beat of the rhythm, There are several ways of doing this, the monostable 
9602 being a TTL compatible which has fast enough performance for this task, the 
74121 being, according to Horowitz and HillÜ not quite so good, and making a mono- 
stable out of a 555 or simply some logic gates, a recipe for trouble according to 
the same book (p.354, first ed.,1980, on monostables),. The data separator way of 
making single-demsity disk data self-clocking was pioneered on the original 8. incl 
floppy disk drive invented by IBM, the IBM3870, and a nice diagram shoving it 
implemented with five chips in. :uding a PLL, the 4046, all on p.122 of R.Graf's, 
Encyclopedia of Electronic Circuits Vol.2, This circuit also uses a dual mono- 
stable, the 74LS221, and with the number of components is sort of a super-duper 
implmentation, The same function it is said, can be performed by a fast clocked 
master-slave JK flip-flop connected as a D-flip flop, the theory being sketched 
quickly in S,Mitka's, "An Introduction To Digital And Analog Integrated Circuits", 
and excellent if slightly turgidly theoretical book, p.208, under Data synchronize 
This might be a harder way to implement it in practice, since the clock of the 
flip flop needs to be just a bit faster rather than for example evenly l, timeD as 
fast, as the data rate, The reason for going into alternatives in such detail is 
that the 9602 i.c. by Fairchild is getting hard to obtain it is said, so it may 
be a practical matter to entertain the idea of substitutes, 

There is a possiblity to get confused here, The 6850, like a floppy disk 
controller i.c, by Western Digital is intended for asynchronous reception of TTL 
sqyare waves, Why does it need to be clocked, in effect being operated as a 
synchronous, or clock synchronized, in other words, device? The asynchronous 
operation that needs a start and stop bit pattern, is the way a whole byte, plus 
any start and stop bits, is transmitted, But within this burst of about 1C-bits 
minimum, there must be a way oftiming it. For this the clocking is extracted from 
the rythm of the bits transmitted, This prevents a run of bits of high or low 
from getting lost as to how many bits should be in the burst, The alternative, 
of transmitting single-pulses, plus a start pulse, of going asynchronous for each 
bit would waste time and disk space, The self-clocking by the 9602 allows the 
asyndmenously sent bursts of a byte of data to encapsulate a synchronized, 8-bit 
byte of data. On transmission of course, this is synchronized by the 125KHz clock 
signal, produced by dividing the 3.58 MHZ color tv crystal frequency down to that 
rate, In the end, since the LDOS system uses the original IBM method of the first 
floppy disk systems, each system contains a bit of history one might say. 


3Four Times? The IBM circuit shows the PLL tuned to 500 KHZ, and the thing to know 
is . hat in this FM system_(of LDOS too), 125KHz is the all-zeros pulse freguenc 
while the all one5 pulse frequency, the maximum, is 250Khz, baude rate still 125i 

@MHorowitz & Hill, The Art of Electronics, lst edition, 1980, Cambridge U./An excel 


lent book} *9602 by Fairchild, 9000 numbers seem used for a/d, data & i/f ic's 


p.7-2 
Memory Locations-ZX-81/ TS1000 


With Larken Disk System Seé p.8-1 for. explanat,. 
of tracks sometimes 
ZX-81/ TS1000 (all addresses in base ten) 


called blocks in L 
Memory Location where earliest machine code can be inserted in first 
REM statement is fixed (rather than floating with TS2068) at 16514 


Memory Location where screen file starts (D FILE) is not fixed as in TS2068 
floats at: PEEK 16396 +256%PEEK 16397 


Memory location where BASIC operating system for computer starts in ROM: ff 
(ROM ends at 8191) i 
Memory Location to which microprocessor goes to seek instructions when 
reset: 


Users/Application Program Starts at memory location (RAM): 16549 
ROM Address where LDOS disk operating System starts; 14336 (3809 hex) 
Location of RAMTOP, a system variable for the ZX-81/TS1000 is fixed at: 
memory locations 16388 and 16389 and the value of RAMTOP can be 
found,. so that RAMTOP=(PEEK 16388 +256%PEEK 16389) 
PPC (RAM) (16392) -equals 255 (FF hex) if computer is in command mode or LDOS 
is in screen command mode‘rather than eing activated from within a 
BASIC program, — —€ 
System Variables for LDOS disk operating system are stored in a separate 


on e face board, 
Current block number (g-79) - 12289 (curtrk) 
Command Line (where current -12316 (Cline) 


command is stored 
Data Buffer begins at 12352 and the first 24 bytes 
contain the variables for LDOS saved in one 
block of data (or loaded in one block) 
including: 
sumcheck 
tile name 


"track P actually block #, 8-79) 
l230L(LSB), 12305 (MSB)-- data T ress (in main computer RAM) start 
123]6(LSB), 12387 (MSB)-- Iength (of data to be saved or loaded) 


Actual Data being saved or loaded starts at 12376 in the 
ata buffer area which is 1960 bytes long max, 
and ends at address 14336 (RAM on disk interface 
board which is 2K in all) 


Port used for saves and loads to turn the disk drive motor on or off etc, 
is port 69 (base 10) and the code used is: 
(1sb) it @- stepper pulse (stepper motor positions head) 
bit 1 - stepper direction (in or out from center hub) 
bit 2 - select side of diskette (top or bottom) to access 
bit 3 - main motor on (main motor rotates diskette) 
bit 4 - write enable (write to disk rather than just read) . 
for example OUT 8 at port 69 will turn motor on 


To Load the buffer- 14546 (loadbf) To set the block # -14778 (settrk) 
To Save the buffer- 14861 (savebf) Increment block # -14763 (nextrk) 
Output data to a port -16374 (output) Sort (interpret Ur a in Cline)- 


144 
(This ROM is on the disk interface board). 
I ——————— A. — (X ADvariace boardje — —— — —  —— —— - 


How The Larken System Works - Disk Organization BRE. qu» 


A 5i" DSDD diskette is sneoreticiliy capable of holding 500K of data,(DD) 
although the standar computers that have made them famous use only 
part of that capacity and store only 360K on them. The Larken system by 
limiting the storage method to single-density cuts that maximum (500K) in 
half from the start to 250K. If the-MS:DOS.and Larken system use 40 tracks,we 
see then there are 40 positionings of the head from the centre of the 
diskette and at each position you can store two blocks of data, one on the 
top of the diskette and one on the bottom, The MS DOS computers can on 
double-density store 5K in each of these positions. ` 
is limited to storing half that or 24K by virtue of using only single-density 
ity storage methods and further cut down to y the use of only a RAM 
buffer on the intérface board. This is further cut down to, 1968 bytes by 
the use of some of that RAM to store LDOS system variables*ànd other bytes 
in it to store special information on the disk so that the disk operating 
System can run more efficiently and not get confused. A further block of 
2K is lost to data storage as it is used to store the information needed 
to pull a directory offthe disk (with a minumum amount of wear and tear 
and wasted time instead of hunting all through the disk for it),A1so here, isa 


Block Map (somewhat equivalent to the FAT, File Allocation Table in MS DOS). 
The first track Uo. contains the directory for the diskette and the 
Block Map, . The 80 bytes reserved for the Block Map contain originally 


the numbers 1 to 79 for the blocks 1 to 79 (block Ø is not included since it 
is always used — for the directory, and Block Map). If a block is being 
used to store a file (a BASIC program typically), then 128 is added to it 
(that is bit 7 is set, bits in a byte go from Ø to 7, right to left, lsb=fth. 

In the directory there are: (after a marker, 253 in base 10), the file 
names(e.g. EXAMPL,Bl), Therefollows in order, the tracks used to store the 
file (plus 128 in each case) Then after,all the tracks are listed 2h spaces 
are allowed for this making the maximum file size 46K, incidently , A marker 
249 (in base 10) is placed to indicate that there are no more (the use of 
such a code thus also limits the number of blocks). A summary of the disk 
codes is as follows: 


LDOS Disk Codes:. -adding 128 to a block number (setting bit 7, MSB) 
makes the block number indicate the block is 
currently in use 

-255,beginning of a block or other general marker 

-25h4, block deleted or not used 

-2h9, end of list of tracks used for a given file 
(they are listed in block jg, the director 
block, after the file name e.g. EXAMPL.B1 

-253, end of file name marker (e.g, EXAMPL,B1,253) 

-256, end of directory marker 


There are 52 possible directory names allowed for in allocation of space 
for names and block numbers in the block used for this (block 2g. Each 
file name (e.g. EXAMPL,Bl) must have the period and a letter (only one of 
A, array, B, BASIC program, C, machine code program), and then one number 
(d to 9). Maximum file name length (the part before the period) is 6 char- 
acters and characters having codes over 248 can't be used (since they might 
be confused with markers), In the ZX-81/TS1000 these are all BASIC command 
codes, RAND, IF, CLS, UNPLOT, RETURN, and COPY, Of course if the file name 
were to be for some strange reason in ASCII or the tokens of another comput- 
er make or model, there might be trouble. This isanother source of incompat 
bility ¥P Also difficulties might arise is ina program running machine | 
code that has the same effect as POKES or a BASIC program that uses POKES 


in a tWéé'random way, Also glitches in the electronics could cause changes in 


such binary information, See page 9-5 (Item 4)for more on this, 
ncompat Li with computers using disks ‘ ^ 
Je EC op AT QU AM A e ae d g with ASCII, etc, codes Aj 


aaa inveriace board Description (Refer To Block Diagram) pe/75 


; The Block Diagram (page 7-6) will show you some of the.basic circuit layout 
features of the interface board more clearly than trying to analyse the schemat- 
ic from scratch, Three parallel buses are shown on the diagram going from left 
(where they plug into the computer's expansion slot at the back of the TS1000/ZX. 
81) to the feed-through edge connector at the end of the board where you can 
place the 16K RAM pack or printer (ZX or TS2040) and then the RAM pack, 
The top bus represents the 16 address lines on the expansion slot bus, the secon 
from the bottom the (microprocessor) data lines, B-bits in parallel, Df to D7, 
and the bottom set of parallel, feed-through lines represent all the other lines 
p expansion slot bus of the TS1000 (other than the 8 data and 16 address 
nes), 

The RAM buffer and the ROM in which the LDOS machine code program is found, 
are simply riding on the address and data lines as additions to the memory map 
of the TS1000 (in the area from the bottom 12K through to the end of the 15K 
area). Other than the power and ground lines and control signals that they get 
from the remaining expansion slot lines drawn as the bottom of the page bus, 
that is all they do. The decoding block of gates, etc. shown as the control box 
decodes the control signals that they need. 

The heart of the data output to disk and input (into the computer) from disk 
is the 6850 chip (U1). It converts the data coming in or going through the 
data bus (coming from or to the SRAM buffer, chip U3, infact), to serial form, 

a single line for disk read going to the latch/self-clocking circuits in the box 
marked 'Latches' for example, and then from there to the edge connector on the 
disk drive unit itself, The write to disk signal is clocked by a 125KHz signal 
(square wave) coming from the oscillator/divider circuit, the signal from a t.v. 
colour crystal (3.57MHz) is divided down by Ul and U15 to the required 125KHz, 
This 125KHz clock signal is fed to both the 6850 chip and the driver circuitry 
in the box marked 'Drivers! and then fed to the disk drive edge connector of the 
disk drive unit itself, 

But more than the data read and write signals are fed to the disk drive 
edge connector to which the disk drive unit is attached. There are AN PORE 
and . QUT PORTS that can be addressed by the machine code in the LDOS operating 
System so that various signals at various Z-80 port numbers can be fed to the 
disk drive via the edge connector going on the disk drive unit itself. These 
signals include start motor, step head from track to track accross the disk and 
so on, They represent the other control signals going to and coming from the 
disk drive unit itself. As examples of signals coming from the disk drive unit 
to the IN PORTiethe track zero line, the ready and the index line all send their 
respective signals to the interface board via this şr- ofis's: They can then be quer 
ried by machine code loops etc, in the LDOS operating system (polling). 

The operation of the 6850 is not simply a matter of serial-parallel conver- 
sion since it is a programmable device and can be given different instructions 
by loading its control register with different numbers and it can be querried 
by the 2-80 to find out its operating status (much like the Z-80 indicates its 
operating status with the Flag register), The 6850 has a similar operating statu 
register itself, In.addition to those two registers it has the parallel data 
registers too, The 6850 is one of the peripheral chips that comes in the 6800 
microprocessor chip set and for that reason more complete information on its op- 
eration may be found in books dealing with the 6800 microprocessor family, in 
the interface chip sections(if the book has then), 

The above text is a quick run through and guided tour through the LDOS inter 
face Block Diagram and should help clarify things for when one wants to or in 
the course of troubleshooting a technician needs to understand the circuit's gen- 
eral operating priciples in order to more efficiently analyse the schematic wirin 
diagram furnished by Larken Electronics, 

Bear in mind that the use of separate chips, the Z-80 to control disk oper- 
ations and the 6850 is not a standard way of doing this anymore, The newer disk 
systems including those sold by Larken Electronics for the TS2068 use one-chip 
disk controllers usually made by Western Digital. At the time the LDOS interface 
board was designed however, these disk controllers were too expensive for a disk 
system aimed at minimum price, for the already low priced Timex-Sinclair market, 
The disk system's specs speak for themselves of how successful this design was, 
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' The 6850 Serial/Parallel Data Converter 
The MC6850 is an integrated circuit that converts the data to b 
saved on disk AE: parallel] (8-bits, on 8 separate data lines) form from 

the 8-line ZX- TS 


1000 data bus to serial form (one bit after another), 
the form that the disk drive unit needs the data in. It also works the 
i the serial data stream (from the disk drive reading i 

r f i utti it i ra form, &-bits 
wide so that it can be stored in the 8-bit wide SRAM chip which makes up 
the interface board data buffer (via the 8 lines of the interface board 
data bus which is an expansion of the 8-line data bus of the ZX-81/ TS1000 
main board), Theresa terminal on the 6850 (pin 2) to read data from the 
diskette and another (pin 6) to write data on to the diskette, A read 
clock signal (helps by finding time duration of pulseS of the 8-bit data gp) 
(on pin 3j by the 6850,8is generated from the data stream itself using the 
9602, precision monostable multivibrator chip. This 9602,will act to 
separate the data bits being read. The timing frequency used 
in writing is 125KHz,° Timing for reading data. bits comes from the 9602 and 
a couple of logic gates, using few chips, For the write operation it is 
generated by a crystal oscillator and frequency divider circuit, 

One of the reasons for selecting the 6850, a 24 pin DIP package i.c., 
was. probably low cost and simplicity of operation, Teo it uses only +5 volts 
and is readily available wholesale since it is one of the 6800 microproc- 
essor support chips, Another, more personal reason may be that the designer 
had taken microprocessor courses at Algonquin College that featured the 
6800 and its support chips, in deference to a local high technology comp- 
any big then, © Mitel, that used the 6800 microprocessor in its telephone 
switch equipment (andneeded software and hardware technicians familiar 
with it). Another type of UART or the ‘Intel family, 8251 could also have 
been used as an e ETTER serial/ parallel converter. 

The 6850 like the 8251 is a programmable interface. Different patterns 
of bit stream transmission can be used, including odd or even parity depend- 
ing on the byte sent to the control register (which is the programming method 
used) by the Z-80A of the ZX-81/ 91000, Using OUT at port 65, decimal 2f is 
loaded into control reg. for 8-bit, no parity, No matter what the format, 
the ago always waits for a stop bit (or two, depending on the programmed 
format) before it is ready to receive the next character, and then a start 
bit at the beginning of that character, Following a transition from the 
normal high state of the data read (input, load), line, there is a timed 
pause followed by eight more timed intervals for the data. Each interval 
may be either a high (1) or a low (g), then the parity check bit follows 
and the stop Bieler: one or two timed intervals of high (+5 volts) voltage 
level, and then the normal high state of the line resumes until the disk 
drive is ready to transmit another character, This start bit, info and stop 
bit sequence thus places timed segments of data in an untimed, normally 
dormant transmission line. This sort of transmission is called asynchron- 
ous, as opposed to continuous or non-stop, in other words, data transmission 
timed by a third line (the second being ground), along which a common clock 
signal passes to keep the receiver and transmitter from getting out of 
synchronization due to circuit value drift causing frequency (standard, that 
is the clock at the receiver versus that at the brananitter|drift. 

The control register is accessed as Port 65, the 6850 status register too 
(which indicates when all 8 bits of data have been received, etc.) at Port 65, 
and the registerBinside the 6850 in which the 8-bits of data are temporarily 
Stored is Port 73. Then to save data on disk, it is loaded into Z-80, reg.A 
from the SRAM buffer on the LDOS interface board and an OUT (73),A puts it 
into the 6850 internal data register from which hardware sends it on one 
bit at a time (plus start and stop bits) to the disk drive mechanism. On 
loading a program from a diskette, the opposite ha pens, the byte being taken 
from the 6850 internal data register with an IN A,(73) and then the Z-80 puts 
it into the appropriate incremented address in the SRAM buffer on the LDOS 
board (from the Z-80, reg.A). 

The 6850 hardware is wired into the address and data bus lines and Z-80A 
__control lines so that it can bekaocessed for data and control by port IN & OUT. 
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Timing Disk Data Access 


Whether you use a floppy disk controller, a 6850 or an 8251 to shunt 
data betwe»the serial data stream of the disk drive mechanism and the micro- 


processor which places the data in memory, timing is a consideration and 
differing approaches can be taken in design. 

In loading a program from disk, the LDOS system uses polling. A test 
loop taking 64 clock cycles to complete one [unsuscosstul) mr best to 
see if a whole byte has been received by the 6850 (interrogates the f bit 
of the 6850 status register at port 65) and if the 6850 is not ready to 
download a byte, continues on another loop bekThe actual routine to read 
the byte from the 6850 into memory takes 57 clock cycles, Each clock cycle 
represents 1/3,25 MHz or Z.3 micro,second. So we are talking of a minimum 
delay through the test routine and read (str) routine and back to test for 


readiness to read a new byte, of 57 + 64 clock cycles-121 clock cycles 
(374 microseconds) This is quite within the specs for single-density (say 
FM) and 125 KHz which requires a minimum time of Ol microseconds. 

However for MFM, double-density written at 250 KHz, a time per byte of 
32 microseconds is specified by one reference work (Microprocessor Based 
Design, by Michael Slater, Mayfield Pub., 1987, p.500). This is the source 
of the LDOS interface's incompatibility with reading or writing to double- 
density disks. To read a doubiS density disk the core routines ttest and str) 
would have to be rewritten to make them execute faster. To write at 250KHz, 
the 125KHz clock would have to be stepped up to 250 KHz by some (probably 
minor) rewiring of the 4017 divider to cut it's divide rate by a factor of 2. 

Rewriting the data-input -from-6850-routine, to make it faster may be pos- 
sible and the writer has a draft (but untested) routine to replace str that 
executes in only 48 clock cycles,(reducing"34à microseconds), If similar 


economies in the*test*routine could be made, it might be possible to get 
it down under the limit so that it could barely have the speed to read a 


,double-density disk. However the rewritten routine has not been tested and 


debugged yet, “Making time savings on theé"'test"rouütine too might be impossilie, 
A hardware modification might also be required of the 9602 circuits when 
running in the faster read mode, to shorten the pulses (Tc) in the data str- 
eam«to accomodate the higher frequency of bits read in double-density. 

Note that the choice of polling or another method to control the disk 
interface does not depend on using a 6850 (or 8251) as the interface chip. 
This choice of polling or interrupt style machine code routines in the DOS 
is also required for floppy disk controller (FDC's) like those of Western 
Digital, The speed of the microprocessor (the slower 8-bit ones like the 
2-80 suffering in comparisson to the faster 8088/ 8086/80286 ana 68000) is 
the limiting factor ultimately, 

Switching to a hardware design that uses the interupt principle might 
have helped, For example if you have a sense line Tron the inte face thi 
which will signal through a NAND gate that the interface is ready to release 
a byte from the register, you avoid the delay of running through the part 
of a polling loop (like test with LDOS), that is not actually testing For 
the ready staat (the instruction that does an IN to the port). In the other — 


parts of the loop, the computer is in effect blind, and must wait for the 
IN instruction to come up again before it can act on it. 


One way of solving this with some interface chips and some microproces- 
sors (in the computer] is to set the microprocessor in wait state (executing 
NOP -no operation = instructions) until the k interface chip sends it a 
ready signal inyerting the signal applied to its delay/ready pin. With the 
Z-80 it is the WAIT signal on pin 24 that operates this way. The IRQ line, 


pin 7, of the 6850 it seems could be used as the other end of this line. 
But now we have digressed into talking about how to redesign the whole inter- | 


| face hardware as well as software] 


Jhe conclusion that the writer would make based on this is that to read 


a double-density disk, software modification would not likely be enough | 
and the experimenter would have to get into harware modification too. To 
write double-density diskettes or format them, hardware modification would 
definitelv be required. ` . 
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IN command in machine language, That 15,1 «t 
The index pulsé sensor (see section on disk drive unit operatio 
ation; p.7-15), similarly is inverted and thus subtr ts 2 from 
on the data bus by setting or resetting bit 1 f the by! -ar 
the Z-80 software, Track. , sensor wor 
8 to the number responding to the quer r 
drive will work on bit 4 and so ad to the. er when 
is querried with an IN command in Z-80 machine language 
ating system program), These are the four bits changed by th 
lines the LDOS interface board connects. the CORE: And: sho di 
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ort 69 is addressed with an OUT instruction in machine anguage 
sent out with the OUT command, | Sadia TRANS the number sent vi 
command), will poras the stepper motor that selects a track fo 
sit over, Bit 1, will determine the direction of stepping (adding 2. to the 
number from the software standpoint), Bit 3 will turn the hub. m r on that 
rotates the disk if set and turn it off if reset (to zero). B 
disk drive in write mode (versus read mode}. -And bit 2 will 
side the data is to be written on. Or: ` reag from tl 
double-sided diskette, ede cd 2 


is a 7A4HCT1TLS . à series of latches or more properly perfil 
which the S Set by the data bus and the Q out pin. Gcnnectec tee an open- 
collector inyerter/driver and then to the input lines for the various control 
functions of the disk drive unit, The chip is selected and the relevant line: 
to the disk drive pulsed by control circuitry conndayed to ehs clock see 
of the flip-flops, A 

The hidden factor? from the: desiguer!s view. te th ta ca: 
seguence between-data and control signals must-be m y the 
ware to make the disk drive function properly, e $rations can- 
be critical, particularly when based on the rather lanny timing relations 
of the ZX- 81/TS1000's timing circuitry as a base, The use of the less 
precise ceramig¢ resonator rather than a quartz crystal for the clock of the 
computer further reduces the designer's latitude here, Using the disk drive 
with a computer with a non-standard, speeded up clook is not recommended! 
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.. ' There are two connectors to the typical disk drive recommended for the LDOS 
system, One provides 45 volts and #12 volts to the drive unit (typically the 12 
volts is from Ø.75 to 1,2 amps, the 5 volts from £.7 to @.9 amps -specs for the 
Shuggart SA155/165). Regulating these voltages through say-a 7805 and 7812 is 
necessary to keep them within the tolerances required, : 

,.À Single-density or double-density drive is recommended, Shuggart, Panasonic 
or another Japanese make, Double-sided disk drives, the so-called IBM-compatible 
allow full capacity @pétiation. 5% inch are recommended on grounds of compatibil- 
ity (most use the 54 inch) over the Seinen Whose diskettes are still too expen- 
sive for the little gain in capacity achieved, Quad-density drives are not recom- 
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Converting Programs That Involve Other Languages p.3-8 


The programs discussed so far have been easier, since they involve either 
BASIC with machine code routines or no "data" Save or load (data in a compiler 
meaning source program saving and loading,most often source not object program 
saving an loading). The most interesting programs for those likely to have 
been prepared to read this far into the technical features of this manual are 
programming language programs, assemblers, compilers and the programs produced 
by such compilers/assemblers, etc. These are unfortunately more difficult to 
fully convert to disk access versions, 


Assemblers 


This writer has had experience with only two ZX-81/TS1000 assemblers, the 
Artic Assembler and the Gladstone, small assembler, The latter is so minimalist 
and hard to use that it is probably not worth mentioning further... The Artic is 
more fully featured and shall be dealt with a little more, (Artic is spelt okt) 


("" equals shift P, twice), Break into the program with the BREAK key just at 
the momentary time of the screen going slack before the second cycle starts 
and you will have the program sitting in RAM in your ZX-81/TS1000, Change 
line ll to NEW, key in GOTO 8 as an immediate instruction. After that you 
should get the &/ 9 message and otherwise blank screen. Key in the immediate 
command RAND USR 3E4 and "ZX Assembler" heading will appear on the screen, and 
you are in 2nd of two modes: edit mode (instructions on p.4 of the assembler 
users! manual) or command/ monitor mode, (instructions on p.11 of the assembler 
users! manual, a list which unfortunately omits the most important instruction 
whieh you would be wise to write into your book right now - E Enter editor mode). 
Attempts to get the peogram to save anything on disk have succeeded only 
intermittently as this is written, 50 little advice shall be given on that 
count now, By saving the whole program, sometimes, the internally entered 
assembly language program was successfully saved and other times not. At 
present this user copies down the assembly language source code and object 
code, if program has tested okay, before making a trial run of the assembly 
or machine code run, so that if à crash results as often does, the work to 
that, point will net be lost in a cloud of bit and byte vapour, Sorry that 
more can't be said, but perhaps the saving problems are related to routines 
to relocate the machine code assembler program, so that once relocated it 
is above RAMTOP or something funny similar to that. 


Integer BASIC Compiler - MCODER II (1983-Personal Software Services, England) 


The writer has tried using the BASIC compiler MCODER II with little 

real accomplishment resulting since it is both an integer BASIC with no decimal 
fractional numbers built in (32767 or something being the largest number, and 
only whole numbers allowed, That means any program involving calculations of 
a technical sort, need you to work out your own routines and write them in 
BASIC, to handle decimal point fractions (or numbers larger than 32,000)... 
However the compiler should be good for some text editor or graphic programs 
and does run programs quite fast, Unfortunately decimal fractions are not 
the only thing missing, and even to get the comparisson, IF A=B THEN ... 

this writer finally realizing that only IF A-B seemed to be supported, used 
the following routine as a substitute - 


100 IF A»B THEN GOTO -somewhere else 

110 IF BOA THEN somewhere else is gone to 

120 whatever you wanted to do if A=B is placed here, since if 
A is not more than B and B is not more then A then they must 
be equal! ...Desperate mesures, but it seemed necessary. 


Maybe this writer only had an old version of the program. 
It is however fairly easily converted to laad and save in BASIC and since 
to run a compiled program the whole compiler with its run-time module, must 
be saved, means that simply saving the whole program with your source code 
inside iL should be good enough for playing with it, which is all this writer 
has done with it so iar anyway. 


Adding Disk SAVE or LOAD To A Program Not Written In ZX-81-Built-In BASIC Pe3-9 

The thing about cassette based programs that you want to fix them to do 
when you get a disk drive is to SAVE or LOAD with the disk now instead of just 
with the cassette. Most programs save or load data by saving or loading the 
whole program, or at least a copy of the program with your work that you want 
saved or loaded, inside that program in the form of variables, Replacing the 
cassette SAVE with a STOP and then saving the program to LDOS disk with the 
saving screen, accessed by PRINT USR 14336, is probably the best way to do 
this. (Of course no CLEAR must be performed to CLEAR the variables that hold 
your data, before you save to disk. It is easy to get the wrong, BASIC cassette 
SAVE one when you are looking for the routine to SAVE with data, and get instead 
the routine to make a copy of the program first erasing the data.) If that is 
all you need to do, that is easy,the easy case of adding disk access to programs, 

À higher level of difficulty is trying to use the LDOS array save (string 
array only, the ZX-81 LDOS does not have numeric array save like the TS2068 LDOS) 
and not save the program, If the program to be adapted is in BASIC, that may 
not be a big problem. If it is in machine code, then you may have to substitute 
a call to the cassette save machine code routine, with a call to a machine code 
routine that you will have to write yourself, to save to disk, the data, It may 
not be possible to do this without beinga.real expert and taking a ton of time, 
especially if the program is copy protected, like Partial Pascal. 

If you are writing a program using an compiler or interpreter other than 
the built-in BASIC of the ZX-81/TS1000/TS1500, then if you want to access the 
disk in LDOS, you of course will find no command in that language to do it, 
since when the language was written, the programmer did. not know about the 
LDOS system, and probably only knew about the cassette system, and may or may 
not have incorporated a routine to save data into the cassette separately from 
program, However, there is an out in most compilers or interpreters, by way 
of the > facility to incorporate calls to your own machine code routines. 
Usually they are just that, calls to machine code that you must write yourself, 
and get into the program in the way the program wants it, either hex or true 
machine code (where "F", the alphabet letter means décrement HL register pair 
contents of #80to give a concrete example. and TAN etc and other things you see 
in a REM statement used to contain m/ à in the same, raw form), It is up to 
you to get your Z-80 machine code into that form using an assembler and/or hand 
conversion. 

What would be in such a program, to save, for example the source code from 
a FORTH compiler, or text from a text editor (word processor) that you might 
want to write a program for in FORTH? In say, FORTH, in this exam le, you would 
have to find out, perhaps by doing a scan of RAM, using PRINT PEEK (X+ 16514), 
where the text ends up when you put it in, using your word processing program, 
(In FORTH there is an additional problem in that it keeps its text in ASCII 
rather than staying with the ZX-81/TS1000 character CODE seen in the back of 
your owner's manual, Second job, is finding out where it ends, perhaps a buffer 
of about 2K will be used in FORTH, dependingrthow closely your dialect of FORTH 
follows this standard custom, In other languages, there may be a fixed length 
or expandable, perhaps some pointer (variable in the internal m/e of the comp- 
iled program) indicating its length or terminaticn, if it is exandable, The big 
thing to test is whether the starting point, or .anything else changes" from 
what you expect it to be and are writing your program around, Some buffers float, 
or use other forms of dynamic allocation, The ZX-81/ TS1000 does not use dynamic 
String array allocation, it would seem but does use dynamic non-array string 
allocation (allocation of memory space, addresses). This you will have to find 
out, beyond a resonable doubt, or even any doubt, because no bug is reasonable 
to leave in a program! (Midifferent compilations and different, runs and user entries,] 

Now you have either the fixed addresses, or a routine, in FORTH or n/c, in 
our example, to find the starting address and ending, address of the block that 
you want to save on disk, Now the LDOS system block save facility, called code 
Save, can be used, and the relevant routines called within this machine code 
subroutine, as explained in the LDOS disk system users manual that comes with 


your system, . : 
k tue other way of doing, it, by saving block by block, in effect, writing 


ati i a iting a 
our own Operating system fragment, is too much work unless you are wri $ 
cutine the operation of which must stay invisible, disk use not showing at'DIRE 


p.2-1 
General Information for the Beginner 


Diskettes - Special Precautions 


There are a number of things that one should bear in mind in using 
the magnetic diskettes (5i inch double-sided double-density) that the sys- 
tem uses, As with cassette tapes you don't want to get finger prints or oil 
on the recording surface which is the brown area showing through the holes 
in the cardboard jacket (which should NEVER be taken off the diskette), Also 
dust or even cigarette smoke's microscopic particles and any hard surface 
(including a note shoved into the jacket with the diskette) should not come 
in contact with the diskette. 

Never place the diskette near a magnet such as your television's speaker 
or on top of your cassette recorder (where the speaker magnet is). Similarly 
diskettes and the drive should be kept a minimum distance away from computer , 
étc, power supplys, radios, monitors, telephones, electrical toys, and etc. 

Never leave the diskette anywhere it might get hot (in a car in the 
summer, on a radiator or heating vent, on top of the t.v, or monitor). Also 
keep any toy or other kind of magnet or magnetic labels far away from where 
you use your diskettes. A special hazard is offered by the X-ray machines 
used by customs at border points and airport security on luggage in damaging 
diskette data.Even spilling any food or drink on them is also trouble. 

If you must write on a diskette label once it is stuck to the diskette, use 
enly a soft, felt tip pen. Paper clips, staples, clamps, folding or creasing 
also are likely to ruin a diskette, When mailing, use cardbeard on both sides, 

Why are we worried about damaging a diskette which may only cost 504? The 
answer is that the program on it may have taken days to write and debug and 
may be lost forever. Which leads us to another thing, always back up your 
work several times, With the Larken disk drive this only takes a matter of 
a minute or two, most of which is time spent in handling the diskettes, If 
you save an updated program under the same label, the old version is lost, 

Proper dust proof diskette boxes for storing dískettes cost only $5-10 


and are a good investment, Some even have locks to keep out the prying, 
inquisitive hands of little ones (who might like to play'flying saucer! etc,)!. 
Formatti a diskette is what you must do before it can be used and 


since formatting writes zeros into the storage area for files and programs 
on the diskette, formatting a used diskette will ruin any data on it. Because 
the whole storage area of the diskette must be written on, formatting takes 
the longest time of any disk activity. So your, DSDD -blank disks right from the 
box or one used on another make of computer for a while will not work on 
your disk drive system until it has been formatted in your Larken system, 

The Larken diskettes will store up to 156K of iar oraetion per diskette. 
Only the amount of the computer program that is in the computer wi e save 
when you save a BASIC program rather than with some other types of disk sys- 
tem: which save the whole 16K. of RAM memory whether it is full or not. ` 

Most people run single-drive systems . while some people use dual-drive 
systems, This manual will refer mainly to the single-drive system, which 
was the one available for testing. E 

Now that you have learned some of the background of the disk based 
storage medium (or reviewed some of the finer points if you are experienced) 
you are ready to refer to the Larkén manual to hock up the disk drive (if it 
is fresh out of the box) and the section on using the disk drive system 
orepared for the average level or beginning user in the next section of this, 


Technical Note 

* Since the buffer stores little Less than 2K to write to each block 

track] due to the fact that some RAM on the interface board is res- 
erved for storing she DOS system variables, and one block (2K) is used 
for the directory of the diskette, 156K versus 160K is more accurate. Of 
Course this figure is for a DSDD diskette, storage at single density. 
Single-sided diskettes will have half the capacity in systems using them 
(80K or 77K corrected capacity) a few of which were sold so that users 


could use a single sided disk drive that they already owned (with another 
make computer . 


Options In Designing å Disk System: Software -A List Appendix V p.A-t 
In order to better understand the LDOS system, one might want to look at 
the options and alternative courses that might have been used. 
a)How to Get The Data Out of The Computer 

1) memory map the peripheral to a certain area or map to a certain port, for 

control, and/or data, input/output - LDOS maps control in & out to ports 

2) use a RAM buffer in the main computer RAM (or accessory extended RAM, e.g. 

in a module, board or cartridge, for the ZX-81/TS1000 Hunter or SCRAM or 
CMOS 1K or 2K RAM extension) -using ZX-81 16K RAM pack is suggested in 
some of the operating system extensions in this book 

3) send data aout to disk drive i/f via a serial or parallel port like printer 

port, RS-232C serial port, cassette ports, reserving a single data line, 

etc. - this port may be built in to the computer, another manufacturer's’ 

accessory (in the case of RS-232C, such a disk ijt could be used by any 

computer that could have an RS-232C i/f built-in or fitted as accessory) 
the data or the control signals could be sent via this route, buffered or 

not, etc. 

4) pass the data in/ out via the main or extension bus, which LDOS does, using 
the 16 address and 8 data lines, using the computer microprocessor as 
the busmaster (Alternate arrangements include using the disk i/f as 
busmaster, or sharing the bus in some way, using a microprocessor on the 
disk i/f board and the main computer microprocessor as co-processors) 


1) pass it direct to the disk i/f electronics, disk controller or UART 1 byte 


own microprocessor 
4) ditto, but in RAM that is a part of computer's main RAM, the File Control 
Blocks, FAB's etc. as used in CP/M, MS DOS, VAX VMS hold the sys. var.'s/ 
DOS control info and separate buffers hold one sector's worth of disk 
file i/o too 


c)Processing/Controiling The Disk Drive Operations 
l)by computer CPU, 2)by disk i/f microprocessor, 3)by dumb disk i/f electronis 
L) by coprocessing, CPU of computer & disk processor working at the same 
time, say one waiting for an interrupt to checking by polling to see 
when the other processor is finished or true multi-tasking 
LDOS chose 1 and 3, to handle disk drive control 
d) Processor Controlling Disk Drive Action Runs-Of Instructions, Where? 
1) computer main RAM, ROM  2)accessory RAM/ROM, 3)disk i/f processor RAM/ROM 
4) complicated electronics with hard-wired logic control -LDOS uses 2,ROM 
located on the LDOS i/f board but connected only to the ZX-81 ext. bus 
e) Where To Put The DOS System Variables, Control Flags? 
1) part of or ext. to ZX-81 sys variable space, 2)computer's program RAM, when 
disk I/O is run as a utility within a prgram running in main computer 
3)in computer's main RAM where built-in or std. O/S says, eg. VAX, FAB's;FCB's 
4) in accessory RAM buffer -LDOS uses the RAM buffer on i/f board altho locat- 
tions of many system variables are transient, overwritten by for example 
CLINE and temporary scratch pad work areas -This raises the question if 
the whole buffer could be better used for a whole, 2K track and sys vars & 


temporary scratch pad memory found elsewhere, in Sys. var area of ZX-81 or 
even ZX-81, 32 char. printer buffer and/or main RAM, or Z-80 CPU stack. 


Appendix V p.A-8 


Options In Designing A Disk System (Continued) 


f) Where to put the data on the disk? 


1) Blocks of equal or different lengths (inner circles can hold less at a 
given bits per inch density of saving data than outer, larger circles 
-note that these circles are sometimes called cylinders) 

2) Sectors of fixed or variable length, or different lengths(a sector better 
tailored to the length of data to save as it falls within one cylinder/ 
circle or its end does, saves on space in à fixed length sector that 
would otherwise be left blank. Variable or different length sectors 
can save on the disk capacity limits, by putting the same number of 
sectors per circle/cylinder from the inside to the outside of the disk, 
yet longer sectors on the outer circles where the circles are bigger, 

than on the inside) 

3) Same number of sectors per circle/track or different numbers, more on the 
bigger tracks on the outside, especially with fixed sector size 

4) Making the disk sector/track layout as close to another recognized stand- 
dard, such as Apple II/Commodore 64 SSDD or 320K or 360K MS DOS DSDD, 
or CP/M of a specific make considered more popular, in the interests 
of compatibility/easier data transfer utilities. 

5) Another varible, how many spare sectors/blocks to allow so that a disk 
copy instruction will still work with a disk not 100% formatted 
ekay or formattable due to bad areas of the disk, disk alignment 
problems, 

6) Put the directory track in the center to avoid disk alignment problems 
or the outer edge (track @ etc.), the IBM MS DOS and CP/M ways 

7) Use a simple system of saving disk tracks/sectors or a more complicated 
algorithm to avoid disk waste especially on repeated saving éresiag 
as dtat is updated and revised and repeatedly saved, revised versions 
replacing older versions, either using the same locations and saving 
over the old ones erasing them or simply using only never used parts 
of the disk to save anything--this being very wasteful. 

£) What disk controller/Density/Magnetic Coding system to use? 
1)Single-density,2Mdouble-density, 3)something different than MFM the 
IBM and CP/M double-density standard usually implemented with a 
Western Digital disk controller chip, rather expensive once, 
h) Mating Software to hardware - speed considerations, disk handler routine 
methods, etc. 
l)interupt driven disk access, 2) polling of data register/disk control- 
ler data register ready status 
.-In short,can the software be made to run fast enough to put the 
hardware through the operations quick enough as the disk turns, 
and relative to the density of bit save/load operation rate 


system design already used by the computer? 
i)Data Transfer Handling -a)Use RAM buffer taken from system RAM like CP/M, 
256 bytes, 512 bytes, or b)use separate RAM buffer on hardware pcb 
Clock Data Transfer l)by microprocessor timing cycles only, byte rate to 
floppy disk controller or serial/paralle I/0 chips, 2)clock also 
by hardware circuit on interface board, 3)clock only by hardware 


m interface board either separate m-croprocessor, 875 UG, oF MS Lic, 

^ In studying the internals of the TDO system, this shor ist o iifer- 
ences between disk systems can be a great help in avoiding the confusion that 
usually occurs when one sets out to read the explanations of disk systems that 
are given in other text and reference books, The reader will tend to get 


stuck on references to one or another peculiarity of a given system, not 
resligine that at ga not ann!3ieahleoe to the savetom that the reader knows . 


System Chart - Hardware p.7-1 


- Intelligence and complicated algorithms, track assignment and directory 
block allocation housekeeping and record keeping is all handled by 
the ZX-81/TS1000's Z-80 microprocessor running m/c from the 2K ROM 
on the interface board, using the 8-line data and 16-line address 
bus of the Z-80 for instruction acquisition (m/c) and data transfer 
to the scratchpad/ systems variable part of the 2K RAM buffer on the 
LDOS interface board, (I/O to the serial/ parallel i.c. is via Z-80. 
port IN and OUT calls, as are control. messages to the LDOS board itself.) 

- The LDOS command interpretation shell is all on the LDOS 2K ROM and uses 

no special RAM areas or ZX-81/TS1000 system variables (that it might 
overwrite-except that the ROM and RAM are mapped into the higher AK 

of the gap in the memory map of the ZX-81/TS1000 from 8K to 16K, beyond 
its own ROM with its BASIC and before the ZX-81/TS1000 RAM -1K, 2K, 16K 
with a standard RAM pack, 32K with a eod ed RAM pack - and conflicting 
with some of the memory mapping of some 64K WE NIA Non-ZX-81 
eode transient tokens are used for SAVE, LOAD, DELETE etc., disk cmds, 

- Block transfers using m/c routines in the LDOS operating system ROM 

are used to form up track-fulls of data in the 2K RAM (using 1960 bytes 

of it for data) but the actual serial transmission (at 125 KHz baud ratd 

to and from the disk drive is via integrated circuit hardware on the 
interface board rather than a dedicated floppy disk controller chip. 

The main part of this is the 6850 serial-parall& conversion and data 

send-receive chip, whose in and out registers are accessed via Z-80 

IN and OUT by a port m/c instructions, Data is written to and read 

from the disk one complete track-full at a time, no sectors being used, 

- Control messages and disk status messages, including the signals to turn 

on the disk drive hub motor and spin the disk and move the head to a 
different track are transmitted using the IN and OUT instructions of 
the Z-80 to transmit these control signals (and receive them) via 
certain port addresses (of the Z-80 address bus), using both address 
lines AO to A7 for port number and data bus for data, 

- Ànalogue to digital conversion and the record/write head driver circuits 
and read/play head senso amplifiers, are all on the 54 inch IBM-comp- 
atible disk drive w^*ich comes with its own p.c.b. with these electronic 
functions and the necessary components for carrying them out, 


-Case, disk drive power supply (usually 12 and 5 volts) and LDOS interface 
p.«c.b. power (5 volts) are extra to that provided with the basic LDOS inter- 
face board and must be provided by or constructed by the user or someone 
prepared to sell these items, Plans for the power supply that could be built 
for this are provided in the original Larken Electronics documentation for 
the interface board. The disk drive mechanical units, depending on vintage 
take about li amps +12 volt, less than l amp, +5 volts and the LDOS board, 
+5 volts only, about $ amp., depending on chips used (74LS, or 74HC etc.). 


Note: for the corresponding software (DOS LEVELS ....) see p. 6-8 
- —and the meshing: of the hardware ind software will be even 
more obvious, 


Software And The Larken TS1000 Disk System 


Lr Pi y S. 
machine code loaded into REM statement 1 by the program as is the usual case) 
using the LDOS disk system will be easy. You just get to the LDOS command screen 
and SEVE"YOUR.BI", or whatever name you give your program and do the similar 
LOAD"YOUR.B1" operation when you want it off disk again. The LOAD will automatic- 
ally clear the rest of memory so you won't end up with fragments of any old, 
previously used program in the computer at time of leading. Thd only confusing 
thing is that on getting a new program that way from disk, the screen will come 
up with the command screen that was on the computer when the program was saved, 
but you are not in the LDOS command mode! Just CLS and press enter if this hap- 
pens and RUN the program the way you would normally after a cassette load. 


If you are a programming experimentor, this probably will start to seem too 
simple after a while and you will want to start using the disk system with little 
disk save and load routines right in the program, so that among other things, the 
program can be made to start running right after loading from disk, with no furth- 
er user commands in between, When you get to this stage, you will want the info 
in chapter 6 and 4 and 5, which shows how to start using LDOS festures in your 
own programs, It is not that hard if you can really get into BASIC programming or 
if you are taking computer programming in school, get your friends or teacher to 
recommend some extra work, books, applications to try, to build up your BASIC 
programming skill. That is the fun thing that owning a ZX-81/TS1000 has always 
been a good entry to. So many people have got their start on the ZX-81/TS1000, 
including some writers for the big computer magazines, that you would be surprised 
if anyone were able to come up with a long list of such people. 

Now you may have a bunch of programs already on cassette for the T$1000/2X-81 
and the conversion of these programs to sk is the main topic covered in the 
rest of this chapter, The main problem in this writer's experience is to get them 
off cassette, many of the cassettes having been recorded imperfectly in the first 
place by companies that used mass dubbing machines, Above all don't zap the comp- 
uter's cassette interface chip by plugging or unplugging the cassette cables while 
the cassette recorder is running. If you do that, or someonw wlse has, it is new 
computer time, although a& few people out there still repair ZX-81/TS1000's for a 
fairly low fee considering the work involved, This writer has found that only 
the use of an accessory like a Winky Beard (by Russell electronics, still sold as 
at 1991, it is believed here) can load some programs and of course an infinite 
patience, and a good, demagnetized and new, properly aligned cassette recorder. 
The other tricks needed to solve the problem in the case of half these programs 
is what follows on the next pages from this point, program by program, 


The next class of programs are the practical ones like databases and spreadsheet 
and even wordprocessors. They are not so easy to convert and the reasons why are 
elaborated in the pages that follow, Enough said for now, 

The final challenge are the programming languages not built in to the ZX-81/ 
TS1000, machine language written compilers, assemblers, FORTH, Pascal, etc.e, that 
you just might want to play with too, The good news is that using them with a 
disk drive is probably the only way to enjoy using these other languages, since 
most are prone to unexpected crashes so that they keep needing to be reloaded. 

4 disk drive is an answer to your dreams here since reloading the program often 
takes 5-10 minutes by cassette well beyond the level of frustration that most 
people can tolerate beyond say five crashes. This means most of these languages 
have never really be n used on the ZX-81/TS1000 before the era of disk drivés, 
The bad news is that the programs having been written before the era of 2X-81/ 
TS1000 disk drives, they make no provision for saving work on disk. Further, to 
modify them to save or load data on disk (that is FORTH programs for FORTH compil- 
er, etc,), you would have to bee an ace machine code programmer and have all the 
technical documentation for the specific compiler, etc., and the latter just does 
not exist, and probably never was written, User manuals don't count for we are 
talking of the internals, sort of trade secrets behind making the compiler, not 
the info you need to merely sue the compiler, The simplest way to go is just to 


load the compiler by disk and save the programs either on cassette or by writing 
them down by hand on paper from the screen (haters running them). 


Operating System Structure p. 6-6 
mfc A oococ 

LDOS Add-On To ZX-81/ TS1000 i / ens Simplified TS1000/2X-81 Operating 
ware rart ne ystem Control Flow 


pdate Scree 


LDOS ROM 


LFY | 3k driv x 
BEL. CDI SEN es) 
ees | Ms 
PAPAS MAIN ZX-81 , 
Byres Ficer Rout. ef MONITOR ROUT. 
“svár ; display fi 
ore m/c Program- 2 eid E 
INTERPRE LDOS disk ecm of a HO 
PARIE Coes monitor, vincent line AE 
entered by VPE 


USR 14336 
BASIC cmd 


HOW || ----LDOS loops-----— ............ . ZX-81/ T81000 Operating System...... 


Zx-8l accessed by USR 14336 loops of control flow 
MIORKS and having its own monitor around main monitor 
ii; ee -directory screen display 
ss erg ug e E cos RR RS ee both can call ROM-calle s. «o - m Xo o m Oo 
n. in ZX-81/TS1000 including 
RST calls in first part 
of memory, to display a character 
Illustration #l- Larken on screen, get character from 
LDOS Disk Controller Working . keyboard, etc. NS 
As Add-On To ZX-81/TS1000 QUPD Ue ende 
Operating System (Note: further explanation page 6-9) 


Operating System As A Series Of Connected Loops 


There are the two ways of looking at operating systems, as a series of 
loops, of which the most fundamental is waiting for a user event such as the 
user pressing a certain key or maybe any key on the keyboard, before going to 
other actions on other loops, or as a series of levels of calls (nesting of 
calls, or levels of GOTO-style loops with conditional exit methods), from 
program routines that do big things and deal with more general things like 
variables, BASIC logical statements, down to finer grain, small things like 
printing one single character to the screen display file and then returning 
to the routine that called it. Big loops, little loops, theytre.all of ae. 

> Let us see the monitor routine as the fundamenta 
loop simply given a name, and a monalithic monitor that 
K uses a lot of machine code, the essentials all in a line 
— - Reme*around the-ioop, rather than a kernel whieh delegates the 
control to subroutines to handle given events needing a 
certain device, often using interrupts to speed access to 
the subroutine needed. But words.are'slow and a picture of 
what a ZX-81/TS1000 actually does with its monolithic monit- 
or, inside its operating system, even if not completely 
Illustration #2 precise or explained in detail, might be better, So here, ILA, 
A fundamental is a picture of the ZX-81/TS1000 with LDOS disk controller 
operating sys .loop|wi th the loops connected,shown in slightly simplified form, 
For further Information on how the ZX-81/TS1000 operating system works on 
these loops, you must use Dr. Logan's ROM disassembly (and a lot of head-scratch- 
ing to fill in the blanks, not thoroughly explained). To help, the names that 
appear in Dr. Logan's book for routines like "Upper" and "Lower" are added to 
our diagram as a cross-feference, If this isnot yet -crean don't stop however, 


Understanding Special Uses Of Words Here AppendixVIIT p.A-l2 
BAT in this manual usually means Block Allocation Table (Chapter 6) and not 
often used as a .BAT-file or batch file as used in MS DOS (the CP/M 
equivalent of SUB, SUBMIT file), although possible ways of making a 
batch file system for LDOS are discussed too. 


m/c -machine code, or machine language, a low level language understandable 
by the ZX-81/ TS1000 microprocessor itself (if Z-80 machine code) 


track/block/cylinder/sector -These terms and confusion between track position 
and track=block, one side of a track position circle, bottom or top, 
are discussed in quite a bít of detail on p. 8-1 mainly. 


CP/M is an.operating system used by many older business and hobby computers 
like the Commodore 128 and Apple II with Z-80 board, It is Trademarked 
and all rights to it owned by Digital Research Corp. although some clones 
of it exist also. The LDOS system cannot run CP/M, because no one has 
done the great amount of work necessary to mate it to the ZX-81/TS1000. 


LKDOS is a later disk system made by Larken Electronics for the TS2068 only, 
and not available for the ZX-81/ TS1000 at time of writing, Jan., 1992. 
It is so different. from the ZX-81 and TS2068 LDOS that it is not worth 
covering in the manual (it needs a manual of its ownl). 


hex - numbers in base 16 that go, O, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, 
E, F at least for each digit ofnumber, 


Z-80 -the microprocessor in the ZX-81/ TS1000 (and TS2068 ,151500, British 
Spectrum, and Cambridge Z-88) 

DOS = Any disk operating system, (In this manual Us not used to mean MS DOS 
only. MS DOS is a Trademark of Microsoft Corp., used for its operating 
system for IBM PC-compatible computers.) 


Integrated circuit- Silicon chip that is a microminiaturized printed circuit 
beard, with many transistors and other components inside. 


i.c. -integrated circuit, see above. 


ASCII - A code for putting letters and punctuation into a computer in the form 
of numbers, in microcomputers typically -bit or one byte is. used per 
character. Each byte stores one binary humber-- from f to 255,'A' being 
65, 8,66, '0,67,'a!97, ?:sign' 63, and so on, The ZX-81/TS1000 like a 
number of home computers does not use the ASCII code but its own, the 
Sinclair ZX-81 code.in the ZX-81/ T81000, Commodore 64 its own code, etc. 


token, BASIC command code -The ZX-81/TS1000 uses some of the codes, $-255 for 
BASIC command words, in addition to 38 for 'A', 39 for“B, etc., such 
as, 200 for COS, 197 for VAL, 198 for LEN, LDOS uses some letter 
type codes for disk operations, 128 for disk LOKD, 129 for SAVE, 
130 fer DIRECTORY, 131 for DELETE and 132 for FORMAT, but these are 
already used by the 2X-81/TS1000 BASIC interpreter, lor some blocek 
graphic character patterns). So the ZX-81/ T1000 code and IDOS — 
codes never meet in the same interpretation routine and so are quite 
separate and independent, For example, SAVE using one key, the 
BASIC token 248 in ZX-81/ TS1000 code is not recognized as SAVE, 
spelled out in separáte letters, the LDOS command, when entered in 
the LDOS command screen routine (or in a REM statement before RAND 
USR 14336). LDOS codes are best considered to be transient codes, 


sector- the LDOS system does not use sectors (a sector is a segment of'atrack) 


DSDD -double-sided, double-deasity, the disks we use. for LDOS 54 inch disks, 
as opposed to SSDD, single-sided double-density or DSSD, double-sided 
single-density, the format written on the DSDD disks by LDOS. 

a.k.a. -also known as 


Components Of A Disk Operating System p.6-7 
A disk operating system is as we have seen a bunch of machine language prog- 
follow aren Loops 


ram routines linked in such a way that the microprocessor can fo £ P 
and make certain choices along the way of what loop or straight run of machine 
language instructions to execute, one by one, These routes through the maze of 
interconnected:machine language instructions have been well-tested and thought 
out by the programmer that wrote the operating system program in all its parts. 
However, what we see when we trace these routes as the microprocessor takes them 
is in fact the computer's internal-eye-view of the disk operating system, We 
don't want to twist our thinking into thinking like a computer so that we think 
in terms of structures of machine language instructions and their possible 
results, The whole point of a disk operating system, or any operating system is 
to get beyond having to think of things we want to get done in the machine's, 
machine language terms, Put a number in a buffer here, take a byte from location 
16666 of the RAM map and place it there instead, and so on .... In fact we just 
want to say to the computer "Save my program." and leave it at that. "How do we 
get from our point of view and our more abstract, higher level of concepts, like 
‘Save my program,', “Load my program labelled, MYPROG,Bl, now," you might ask? 
It is by taking those commands, thinking of what they mean, all the operations 
and checks that they will require, and making a program to translate these big 
ideas, general commands, into the appropriate list of machine language accomplish- 
able operations that the lassie apd 368 ain gets from the human to machine level, 
In order to analyse How the problem must be solved from the programmer's ` 
point of view, we can analyse the big, higher level concepts like SAVE for a 
program into a lot of middle level concepts, like at is a program?" The ZX-81' 
as an answer to the question of what a program is and its detailed machine lang- 
uage level definitions of memory locations, etc., and our LDOS system decided to 
adopt these standards, so that "SAVE" in LDOS means simply (for BASIC programs) 
save a ZX-81/TS1000 program as previously defined by Sir Clive Sinclair, who made 
the specifications for a ZX-81/TS1000 program, So Sir Clive's definitions of 
BASIC program and BASIC string array were kept so that/méeans- the LDOS disk operat- 
ing system could simply save both as defined on the ZX-81/TS1000 and usable by 


it, just as if they had.been saved on cassette tape, This is how to look at the 
LDOS system from the human point of view; see levels of coneepts that bu up 
at their highest and most complicated level of intelligent control, into something 


close to what a human means when he tells another human being to save something. 


As we have seen, the top, highest, most intelligent level of analysing the 
way LDOS works, is that closest to E concepts Tor TE and DELETE, etc.) and 
the nex eve S that designed to deal with concepts. already defined for the 
ZX-81/TS1000 in its BASIC operating system (as the'ZX-81/TS1000 comes with, before 
any disk system is attasliedi things like BASIC program, BASIC string array and 
block saving of a'block! of RÁM (as used in machine language programs for the 
ZX-81/TS1000) and called in the Larken LDOS Owner's Manual, code save, Similarly 
FORMAT and DELETE have been incorporated into LDOS just the way these highe level 


concepts have human meaning in other disk operating systems (like those of the 
IBM PC, MS DOS, etc.). 


At still lower levels or layers of LDOS, the LDOS system calls into use as 
needed ZX- TS1000 primitives Tie print-a-characterxto the screen, open the 
serial/ parallel integrated circuit output control register for change of output 
parameters, put a byte of data now in the serial/parallel 4.c. into a certain spot 
in the LDOS RAM buffer when it is ready and has all 8-bits of it read off the | 
disk spinning in the drive, etc, The commands that LDOS uses at the higher level « 
are also called the shell of the LDOS system, something that protects it and the | 
data on disk that it handles from being scrambled by the operator making a well- 
intentioned but mistaken choice of a machine language instruction, in a list of 
them, to do something to get a program saved or loaded, like quo a wrong RAM 
address by mistake. , (**in ZX=81/TS1000 a ROM call, RST 10) 

Levels of the LDOS in-between the primitives and actual machine code to do 
manipulation of the LDOS board's serial/parallell/O i.c., and the human understand- 


able command like SAVE, include those routines handling and not “hosing track of 

where a program is stored on disk, so that a BASIC pregram may need several 1960 

bywtracks to store it all, each track given a header at its Start, giving the 
rogram name, and where to restore it in ZX-81/TS1000 RAM when ir] o it back in, 


or one example, Other computers! DOS programs have other primitives like those 
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used in some multi-tasking or multi-user operating systems that protect ór. track 
file access and these can be implemented by file stamping as well as other ways. 
MS DOS hidden files come as close to this we will: likely/see and protected and 
read-only file modes of MS DOS make up these sort of control attributes for files 
that attempt to seal-off the activities of one kind or time (in multi-tasking) 
when applied to a given file. (See page 6-6 for illustration of LDOS loop struct.) 
At this level we are still dealing with handling data in b tes, and we have 
to move down to the still more primitive input-output bit or serial level at which 
the floppy disk in/eutput - chip receives its commands to load or save its. buffer 
worth (typically one byte) of data one bit at a time. This may be implemented part 
in software and part i using a complex chip like the floppy disk controller or 
by more and more software and more primitive components right down to the level 
of comparators and TTL chips, and op amp amplifiers and disk head coil drivers, 
Luckily modern disk drives have all the digital/analogue interface components on 
a printed circuit board of their own, and the LDOS uses a complex serial-to-parai- 
lel (and vice versa) chip*to avoid going down to the level of TTL chips and ^ 
shift register to step the bits in and out to the disk drive electronics, It. 
also avoids the approach of the Commodore 64 in which its disk drives are miniature 


computers in themselves with their own microprocessor. running the show. So to 
summarize we have: 


DOS LEVELS IN A TYPICAL SYSTEM 


First Level Overall controller ---- user interface DOS command shell, 
(Intelligence) command entry/capture-sys, ——— 
Sa$ Ga: Level File Handling/Directory/Block Tracking and Control 


(Clerical RAM and 
block co-ordination) 


hird T Primitives to Load A Block from Disk 
TDA ceo Save a Block to Disk and : 
(loadbuf, savebuf) Seek a Block location on disk 
Fourth Level Control Mechanism to Control The 
interface with the 
binge ee itself) serial-parallel conversion of data 


(computer needs parallel form, bytes, disk 
drive unit needs serial form, bits) 


Sending control signals to the disk 
and receiving acknowledgements, status 
reports back (may be done in hardware 
and linked largely to the overall controller 
routines, in part or also to the primitives) 


Diagram #1, Software Functional Lexeig;In A Disk System 
(See also the corresponding hardware chart in section/chapter 7 to seerelation;) 


The classification in this analysis is highly arbitrary. Nonetheless it 


cc make a good illustration of the thinking and elements the analysis seeks to 


identify. Having such an overview in mind can simpiify-the peek that is to 
follow, into a true and elaborated disk operating system, 


——— —— — — — ot me oe 


yw also avoided using a specialized floppy disk controller chip, too expensive 
at the time to put in a disk interface that had to be low cost to sell at all. 


—————————————————M' A AB ON o CAC CT ON eat pw nr ces enamine sen os 


^n Appreciation Of Technical Modifications Possible With The LDOS System Pe 7- 


If we had to redesign the LDOS system, what could we say might have been done 
differently? For one thing, from today's perspective, some of the components used 
in the LDOS board in the mid-1980's for reasons of economy could be replaced by 


better ones without much extra expense now, Afloppy disk controller i.c. allowing 
‘he use of double-density and reading common 5à inch MS DOS and CP/M disks and  - 
even writing text files to them with a special software utility, as a result of 
usine such a floppy disk controller, would be the best improvement, The floppy 
disk controllers sold then were simply too high in price. The second improvement 


would be to use a longer track for saving items, the track length limited by the 
price being limited to use of a 2K RAM buffer on the disk controller bo&rd, a 4K 
static RAM now not too pricey, would have allowed, with battery back-up a place 
to put user written utility routines, custom command shell, etc. and other disk 
utility routines, and still increase the bytes per track to about 24Kbytes, over 
the 1950 bytes of the current system, That would push the memory capacity of a 


disk from the current 151K to about 192K per disk, An extra 41Kbytes per disk is 
not^ing to sneeze at by way of improvement, a 27% gain, — — ENO E 


— A better provision for single-sided disks and other ways of being flexible 

would have made the double-sided 3} inch disk practical, at 160 tracks of the 

evict! ing 1960 bytes per track, 304Kbytes per disk would make them viable economic- 
ally. At present, due to the MES of the block allocation table, etc., only 

9c 181K capacity per disk, and so too small to make 
the use of the more expensive 34 inch disks practical, A single-sided 34 inch drive 
sould with some minor changes to the software in ROM, be used for a novelty, but 

at no greater capacity than the current 5$ inch disks, that is 151K. So that is 
not much good unless you want to pay a premium for small storage, as in mailing 

the disks cheaper, 

Tf the interface had to be redesigned now, for example, due to a last ditch 
attempt to salvage some data on a disk, the RAM and ROM/eprom wiring could be 
simply left out, and a surplus 64K RAM pack used instead, The LDOS operating 
cystem would have to be loaded in to the correct region of the 64K RAM pack on 
every power up, but then since that is only 2K, plus any program routine to do 
‘he actual relocation, that would not be a big problem, It would however elimin- 
ate one of the major benefits of the LDOS system as it stands now, the ability to 
recover quickly from a crash (keyboard lock-up) when trying anunsual program or 
cebdueging machine code, One other thing that would likely have to be redesigned 
vould be the circuit using the 9602 chip which is said to be obsolete and no,longer 
on the market. There also could be a few other tricks to try with it, after add- 
ine a reset switch, adding a serial interface, would be an easy extra item to 
ausm-nt a new design with, and the 6552 chip could be used to replace the 6850 
sc well for the main serial-Parallel conversion function, If the electronics were 
canted back to a minimum by avoiding the use a on board RAM and ROM, the design 
nicht get simple enough to hand wire using wire wrap technology. 

hs for the operating system, there are a few bugs that could be eliminated, 
including the random failure to carry over to the next page of a directory when 
the writing of the text goes to the bottom of the screen, An ASCII editor could 
be ^uilt into an expanded RAM, as an extra bonus if a serial interface or modem 
allowed the use of file/data transfer, for which ASCII would be needed at some 
point to get compatibility with the other computers, most of which use or can 
handle by some utility program, ASCII text. one can handle ZX-81/TS1000 code, 
simrly because no one cther than a TS fan would bother to write a program to do it, 

^ne of the things that makes the LDOS RE system lean and mean and a 
tight design conceptually, is also one of t things that makes it monolithic and 
hard to modify. It would be nice to replace all the points that branch back into 
another point, for example the monitor, with some sort of subroutine structure, 
Th^t way low level routines and medium level also could be called, wihtout having 
them at the end, branch back into the LDOS screen monitor, However, this might run 
into what the writer suspects is a stack memeory shortage in the ZX-81/TS1000 
which seems to prevent nesting of BASIC GOSUB's more than twice and certain other 
nested calls, as the definition inside a definition bomb of ZX-FORTH, reported by 
one user, Some languages and implementations in other computers do have the 
"Programmers needing to watch how the stack is getting along, how close to being 
fall. and this may be another example of the phendémenon. it remains to.be proved, 

Jn summary, the system is very neat, very lean and very automatic, as it is, 
but oj course given more effort, one could improve virtually anything. 
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